https://bugs.winehq.org/show_bug.cgi?id=47894
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |5da10c9a0e405c4b502be820ae0 | |385d634306a76 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Severity|normal |major
--- Comment #7 from François Gouget fgouget@codeweavers.com --- The initial report does not mention the actual test failure. So here it is for reference (unless I'm mistaken):
winstation.c:973: Test failed: unexpected foreground window 00070064
These days it impacts a relatively wide range of Windows configurations regardless of bitness: w2008s64, win7u64-1spie9 (French and Spanish), w1064v1809 (French, Hebrew, Japanese, Portuguese, Russian).
See: https://test.winehq.org/data/tests/user32:winstation.html
Furthermore the window handle changes with every run which means this failure is "always new". Because of this the TestBot will report most user32 patches as responsible for this failure which should cause them to be rejected. Thus fixing this issue is high priority.
Note that a workaround for the "always new" aspect would be to not include the window handle in the failure message. Including the window title instead may actually make more sense and would avoid most of the false positives.
The commit that introduced this test is:
commit 5da10c9a0e405c4b502be820ae0385d634306a76 Author: Qian Hong qhong@codeweavers.com AuthorDate: Tue Oct 8 11:40:26 2013 +0800
user32/tests: Added foreground window tests on different desktops.
Looking at the reports on test.winehq.org there are two main types of windows that cause this failure:
* "Unable To Locate Component" dialogs (all w2008s64 failures) As mentioned in the previous comments: mfreadwrite_test.exe - Unable To Locate Component
These are triggered by WineTest itself when it tries to get the list of test units. See the "load error 1359" bug 48062. But I would argue these are far from the majority of the troublesome windows. Interestingly there are a couple of cases where user32:winstation did not fail on w2008s64 despite the presence of the "mfreadwrite=load error 1359" error. Does this window go away sometimes?
* "FileSyncConfig.exe - AvP[V G[" (1x w1064) This is a OneDrive dialog on Windows 10 :-((( WTH!!!
* "Program Manager" window (1x win7u64-1spie9-fr) Program Manager
* "" untitled window (1x win7u64-1spie9-es) No idea what this is.
* "Application Error" dialogs (11x w1064) amstream_test.exe - Application Error crypt32_test.exe - Application Error d3dcompiler_43_test.exe - Îøèáêà ïðèëîæåíèÿ ddraw_test.exe - Erro de aplicativo dwrite_test.exe - Erreur d'application ieframe_test.exe - Erreur d'application inetcomm_test.exe - Erreur d'application kernel32_test.exe - Erreur d'application
These all correspond to timed out tests. Yet, as far as I can tell WineTest kills tests that time out. So this means that either TerminateProcess() failed or that the window did not belong to the process (DrWatson?).
It may be possible to modify WineTest to get rid of the two main sources of these windows; and it should be possible to reconfigure OneDrive so it does not pop up dialogs.
However I would argue that winstation should just be more robust. Except for the three outliers (Program Manager, OneDrive and untitled window), I suspect that the window was present long before user32:winstation started. That should make it easy to detect it (or them?) and take it into account so the test does not fail; or even to skip that part of the test.