[Bug 47894] Error dialogs cause the user32:winstation tests to fail

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47894

François Gouget <fgouget at 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 at 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 at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.