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.