Stefan Dösinger : d3d9/tests: Don't fail test_reset_fullscreen if the WM resizes us.

[Alexandre Julliard]

Module: wine
Branch: master
Commit: 4bc8b73cf34175faea59b152878c484d16d7feda
URL:    https://gitlab.winehq.org/wine/wine/-/commit/4bc8b73cf34175faea59b152878c484...

Author: Stefan Dösinger 
Date:   Wed Sep  6 14:11:07 2023 +0300

d3d9/tests: Don't fail test_reset_fullscreen if the WM resizes us.

fvwm does that for two independent reasons. The important thing is that
we don't receive a WM_SIZE during the reset call itself.

---

dlls/d3d9/tests/device.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c
index 8284e3365c8..d36b76156f5 100644
--- a/dlls/d3d9/tests/device.c
+++ b/dlls/d3d9/tests/device.c
@@ -4757,6 +4757,7 @@ static void test_reset_fullscreen(void)
     IDirect3DDevice9 *device;
     WNDCLASSEXA wc = {0};
     IDirect3D9 *d3d;
+    RECT r1, r2;
     HRESULT hr;
     ATOM atom;
     static const struct message messages[] =
@@ -4835,7 +4836,35 @@ static void test_reset_fullscreen(void)
     device_desc.flags = CREATE_DEVICE_FULLSCREEN;
     ok(SUCCEEDED(reset_device(device, &device_desc)), "Failed to reset device.\n");

+    /* We shouldn't receive a WM_SIZE message during the reset because d3d filters
+     * messages sent to the focus window. This is important because some games
+     * respond to WM_SIZE messages by calling Reset(), resulting in an endless
+     * recursion. */
+    ok(!wm_size_received, "Received unexpected WM_SIZE message.\n");
+    GetWindowRect(device_window, &r1);
+
     flush_events();
+    GetWindowRect(device_window, &r2);
+
+    /* fvwm2 and 3 resize the window though. We learn about this when processing
+     * events, after Reset() has finished and d3d is no longer filtering window
+     * messages. This still shouldn't happen but won't lead to an endless recursion.
+     *
+     * As far as I understand the fvwm3 source code, the WM doesn't expect a window
+     * to change from size A maximized to size B maximized. It will un-maximize the
+     * window, picking the stored normal size - which appens to be the size of the
+     * first fullscreen mode above, but not necessarily the screen size at startup.
+     *
+     * fvwm2 on the other hand doesn't understand mode switches at all. It will see
+     * the window is fullscreen (it has separate flags for fullscreen and maximized),
+     * and try to resize it to what it thinks is the display mode - which is the mode
+     * that fvwm2 was started with. The above fvwm3 bug also exists in fvwm2 but is
+     * hidden by the mode bug.
+     *
+     * This comment is based on a very superficial understanding of fvwm's event
+     * and window dimension handling code, which is about 10k lines of code. So it
+     * may be wrong. */
+    todo_wine_if(!EqualRect(&r1, &r2))
     ok(!wm_size_received, "Received unexpected WM_SIZE message.\n");

cleanup: