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.

Here is at least one test failure in gitlab CI: https://gitlab.winehq.org/Alcaro/wine/-/jobs/28526

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

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.

All the TestBot VMs that run fvwm* (debian11, debian11b, debiant) have UsePPosition since 2023-09-21 but this failure persists :-(

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/27fd3caea6a89444bfe4f19dd5a2233793c591c3 (which will land in our images someday in the far future).

Closing bugs fixed in 10.0-rc2.