[Bug 55583] New: d3d8:device - test_wndproc() often gets an unexpected WM_WINDOWPOSCHANGING in Wine
https://bugs.winehq.org/show_bug.cgi?id=55583
Bug ID: 55583 Summary: d3d8:device - test_wndproc() often gets an unexpected WM_WINDOWPOSCHANGING in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com Distribution: ---
d3d8:device - test_wndproc() often gets an unexpected WM_WINDOWPOSCHANGING in Wine:
device.c:3221: Test failed: Expected message 0x46 for window 0, but didn't receive it, i=1.
See https://test.winehq.org/data/patterns.html#d3d8:device
This specific case started happening on 2023-09-08. A similar failure happened in the past but only for i=0 while in the WineTest runs this failure only happens with i=1. A bisect shows that this specific failure started with the commit below:
commit 763dc064504d729029f227e220c858fdb8a8178e Author: Stefan Dösinger stefan@codeweavers.com Date: Wed Sep 6 14:40:52 2023 +0300
d3d8/tests: Don't check messages when doing the minimization workaround dance.
https://bugs.winehq.org/show_bug.cgi?id=55583
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |763dc064504d729029f227e220c | |858fdb8a8178e Keywords| |regression, source, | |testcase CC| |stefan@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=55583
--- Comment #1 from Stefan Dösinger stefan@codeweavers.com --- This affects the linux_newtb-debian11 machines right? It is using fvwm2 according to the description. Are you using UsePPosition for them? (See wine commit c7d748d2e5).
Even with fvwm's default of randomly ignoring client position requests the test seemingly passed previously, so I'll try to do something about it. I can't promise that I can do more than add a flaky, or revert the patch and add a flaky to the original WM_ACTIVATEAPP failure.
I think you confused two different windowposchanging failures - the one where a WM_WINDOWPOSCHANGING message arrives but is not expected, and this one here, where we want a WM_WINDOWPOSCHANGING notification.
https://bugs.winehq.org/show_bug.cgi?id=55583
--- Comment #2 from Stefan Dösinger stefan@codeweavers.com --- Here is at least one test failure in gitlab CI: https://gitlab.winehq.org/Alcaro/wine/-/jobs/28526
https://bugs.winehq.org/show_bug.cgi?id=55583
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|d3d8:device - |d3d8:device - |test_wndproc() often gets |test_wndproc() often is |an unexpected |missing a |WM_WINDOWPOSCHANGING in |WM_WINDOWPOSCHANGING in |Wine |Wine
--- Comment #3 from François Gouget fgouget@codeweavers.com --- I did mix up the missing message and unexpected message cases. I'll fix the bug summary at least.
As of today the TestBot VMs don't have UsePPosition in their fvwm* configuration. See: https://wiki.winehq.org/Wine_TestBot_VMs#Unix_configuration
https://bugs.winehq.org/show_bug.cgi?id=55583
--- Comment #4 from Stefan Dösinger stefan@codeweavers.com --- TL;DR: Gitlab CI fails the same test very rarely even with UsePPosition. I'll defer the !UsePPosition case until I understand what's still going wrong on gitlab.
Fundamentally I don't think we can make any tests that check the window position pass if the WM randomly decides to ignore our requests to set it. I also saw major problems with Linux apps with the default fvwm config - my kwrite windows were placed partially off-screen, with the title bar unreachable. Fullscreen Linux games like tuxracer and neverball also randomly had title bars or not.
That said, the reason why this passed before is that the test does a number of window position changes (minimize, restore, set focus, make fullscreen). What we ideally get is a WM_WINDOWPOSCHANGING + WM_ACTIVATEAPP(activate), with the WM_WINDOWPOSCHANGING being the result of the "make fullscreen" step.
What happened before 763dc064 is that the minimize step incorrectly deactivated the window, even though it wasn't supposed to be active in the first place. But the minimize and restore steps would unintentionally satisfy the "receive a WM_WINDOWPOSCHANGING" requirement. The test failure was then the "received unexpected wparam 0, expected 1" line. But with 3 possible size changes fvwm was unlikely to ignore *all* of them.
Now we don't receive an unexpected WM_ACTIVATEAPP(deactivate) any more because we don't check messages during deactivation. But then we have only one chance to get the intentional WM_WINDOWPOSCHANGING, and if fvwm thinks its a bad idea to make the window fullscreen in this particular moment we don't receive it.
Gitlab CI still had at least one failure in the same line (I think, I lost the link). So even UsePPosition doesn't reliable avoid it and/or there are two bugs that cause the same symptom.
https://bugs.winehq.org/show_bug.cgi?id=55583
--- Comment #5 from François Gouget fgouget@codeweavers.com --- All the TestBot VMs that run fvwm* (debian11, debian11b, debiant) have UsePPosition since 2023-09-21 but this failure persists :-(
https://bugs.winehq.org/show_bug.cgi?id=55583
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED CC| |rbernon@codeweavers.com Status|NEW |RESOLVED
--- Comment #6 from Rémi Bernon rbernon@codeweavers.com --- This seems to be fixed, there's still similar errors on KWin setups, but I would rather blame KWin and otherwise the tests have passed on most config without errors for a few weeks now.
Fwiw there's still an existing bug in fvwm which randomly and occasionally lose focus, this will be fixed in fvwm3 (fvwm2 stays affected and the same fix wasn't merged because it is now unmaintained) with https://github.com/fvwmorg/fvwm3/commit/27fd3caea6a89444bfe4f19dd5a2233793c5... (which will land in our images someday in the far future).
https://bugs.winehq.org/show_bug.cgi?id=55583
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 10.0-rc2.
-
WineHQ Bugzilla