https://bugs.winehq.org/show_bug.cgi?id=53230
Bug ID: 53230 Summary: user32:win - test_activateapp() fails randomly with fvwm Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com Distribution: ---
user32:win - test_activateapp() fails randomly with fvwm. The failures themselves change quite a bit from one run to the next, depending on where in the function the failures start. It looks a bit like a race condition between the test and the window manager. Here is a relatively complete set:
win.c:10976: Test failed: Expected foreground window 0, got 01DE007C win.c:10982: Test failed: Expected foreground window 001A013C, got 01DE007C win.c:10992: Test failed: Expected foreground window 001A013C, got 00000000 win.c:10999: Test failed: Expected foreground window 001A013C, got 01DE007C win.c:11001: Test failed: GetActiveWindow() = 00000000 win.c:11001: Test failed: GetFocus() = 00000000 win.c:11003: Test failed: Received WM_ACTIVATEAPP(0), did not expect it. win.c:11011: Test failed: Expected foreground window 001A013C, got 00000000 win.c:11013: Test failed: GetActiveWindow() = 00000000 win.c:11013: Test failed: GetFocus() = 00000000 win.c:11021: Test failed: Received WM_ACTIVATEAPP(1), did not expect it.
https://test.winehq.org/data/patterns.html#user32:win
The failures don't seem to depend on the locale or bitness. However they only happen in the TestBot VMs which happen to run fvwm (with a specially curated configuration file) and don't happen on my box which runs KDE for instance.
https://bugs.winehq.org/show_bug.cgi?id=53230
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
https://bugs.winehq.org/show_bug.cgi?id=53230
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
--- Comment #1 from Rémi Bernon rbernon@codeweavers.com --- There's a race condition in user32 when multiple window activation messages are queued, without being processed, and are later processed in the wrong order because of recursive message processing.
Then there's also a race condition with X11 window activation events, which are coming late and which are racing against normal user32 window activation logic by re-activating windows that already went through the activation logic once. This isn't going to be easy to fix as there's no way to tell X11 activation events that the result of a window being mapped or restored, from activation events that come from a user interaction.
https://bugs.winehq.org/show_bug.cgi?id=53230
--- Comment #2 from François Gouget fgouget@codeweavers.com --- Here is a variant which sometimes happens alone and sometimes is followed by the original set of failures:
win.c:10983: Test failed: GetForegroundWindow() = 00E80082