[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(a)winehq.org Reporter: fgouget(a)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(a)codeweavers.com> Date: Wed Sep 6 14:40:52 2023 +0300 d3d8/tests: Don't check messages when doing the minimization workaround dance. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=55583 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |763dc064504d729029f227e220c | |858fdb8a8178e Keywords| |regression, source, | |testcase CC| |stefan(a)codeweavers.com -- 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.
https://bugs.winehq.org/show_bug.cgi?id=55583 --- Comment #1 from Stefan Dösinger <stefan(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=55583 --- Comment #2 from Stefan Dösinger <stefan(a)codeweavers.com> --- Here is at least one test failure in gitlab CI: https://gitlab.winehq.org/Alcaro/wine/-/jobs/28526 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=55583 François Gouget <fgouget(a)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(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=55583 --- Comment #4 from Stefan Dösinger <stefan(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=55583 --- Comment #5 from François Gouget <fgouget(a)codeweavers.com> --- All the TestBot VMs that run fvwm* (debian11, debian11b, debiant) have UsePPosition since 2023-09-21 but this failure persists :-( -- 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.
https://bugs.winehq.org/show_bug.cgi?id=55583 Rémi Bernon <rbernon(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED CC| |rbernon(a)codeweavers.com Status|NEW |RESOLVED --- Comment #6 from Rémi Bernon <rbernon(a)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). -- 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.
https://bugs.winehq.org/show_bug.cgi?id=55583 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #7 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 10.0-rc2. -- 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.
participants (1)
-
WineHQ Bugzilla