This MR fixes this random failure: http://test.winehq.org/data/126363ea5f9056449e8bd22cc69b51bd2d7dd9aa/linux_n...
It happens mostly in d3d9, but if you try hard enough you can see it on d3d8 too.
There are more random failures in test_window_position that I have seen when running on an actual display but not in a dummy X server or Xephyr. One failure mode is that we lose focus in the initial create_device and minimize ourselves. This particular problem is specific to focus follows mouse. Another is that fvwm seems to place the window slightly offscreen, maybe shifted by the size of the window decoration. I am still looking into those issues.
Unrelated to test_windoow_position, there is at least one more random failure in test_wndproc (Test failed: Expected message 0x46 for window 0, but didn't receive it, i=0.), so expect more fvwm3 related MRs after this one...
From: Stefan Dösinger stefan@codeweavers.com
This fixes random failures on fvwm3. --- dlls/d3d8/tests/device.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c index b61ad207cc9..7efb5485300 100644 --- a/dlls/d3d8/tests/device.c +++ b/dlls/d3d8/tests/device.c @@ -10897,6 +10897,15 @@ static void test_window_position(void) ret = SetForegroundWindow(GetDesktopWindow()); ok(ret, "Adapter %u: SetForegroundWindow failed, error %#lx.\n", adapter_idx, GetLastError()); flush_events(); + + /* In case of premature restoration of the window (fvwm2/3, randomly), try again. */ + if (GetForegroundWindow() != GetDesktopWindow()) + { + ret = SetForegroundWindow(GetDesktopWindow()); + ok(ret, "Adapter %u: SetForegroundWindow failed, error %#lx.\n", adapter_idx, GetLastError()); + flush_events(); + } + ret = ShowWindow(window, SW_RESTORE); ok(ret, "Adapter %u: Failed to restore window, error %#lx.\n", adapter_idx, GetLastError()); flush_events();
From: Stefan Dösinger stefan@codeweavers.com
--- dlls/d3d9/tests/device.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c index c972e97f572..a279a3c8acc 100644 --- a/dlls/d3d9/tests/device.c +++ b/dlls/d3d9/tests/device.c @@ -14933,6 +14933,15 @@ static void test_window_position(void) ret = SetForegroundWindow(GetDesktopWindow()); ok(ret, "Adapter %u: SetForegroundWindow failed, error %#lx.\n", adapter_idx, GetLastError()); flush_events(); + + /* In case of premature restoration of the window (fvwm2/3, randomly), try again. */ + if (GetForegroundWindow() != GetDesktopWindow()) + { + ret = SetForegroundWindow(GetDesktopWindow()); + ok(ret, "Adapter %u: SetForegroundWindow failed, error %#lx.\n", adapter_idx, GetLastError()); + flush_events(); + } + ret = ShowWindow(window, SW_RESTORE); ok(ret, "Adapter %u: Failed to restore window, error %#lx.\n", adapter_idx, GetLastError()); flush_events();
Zhiyi Zhang (@zhiyi) commented about dlls/d3d8/tests/device.c:
ret = SetForegroundWindow(GetDesktopWindow()); ok(ret, "Adapter %u: SetForegroundWindow failed, error %#lx.\n", adapter_idx, GetLastError()); flush_events();
/* In case of premature restoration of the window (fvwm2/3, randomly), try again. */
if (GetForegroundWindow() != GetDesktopWindow())
I can't reproduce this error on FVWM2. I can reproduce the one at d3d9/device.c#L14926 though.
Another is that fvwm seems to place the window slightly offscreen, maybe shifted by the size of the window decoration. I am still looking into those issues.
I think they are the same issue. So I suppose it's better to wait until you figure out why FVWM2/3 shifted the position and come up with something better instead of this workaround. I can confirm the -9 is from FVWM2 sending a new ConfigureNotify event. You can trace the calls to SendConfigureNotify() and find out where the -9 is coming from in FVWM2.
One issue I encountered previously is FVWM2 not respecting PPosition fully by default. Please see c7d748d. Does FVWM3 need the same settings?
Yeah I was indeed running this without UsePPosition by accident. Setting it makes this test here work a lot better, although there is still the case of randomly minimizing the window right after the initial create_device.
I'll close the MR for now but might come back to the idea later if I still see this fail despite UsePPosition.
This merge request was closed by Stefan Dösinger.