On Thu May 8 20:01:02 2025 +0000, Elizabeth Figura wrote:
Yeah, I'm not proposing to replace the entire tests, just that we should replace that specific test (was WM_WINDOWPOSCHANGED received) with a more direct test (does Reset() recurse forever).
I had another look at this. The nature of the WM_WINDOWPOSCHANGED messages differ.
On Wine (with kwin as window manager at least), the WM_WINDOWPOSCHANGED messages occur during the flush_events() after SetForegroundWindow returns. So they happen after d3d's message handling. Calling Reset() from the window handler in this situation will break follow-up tests. We could adjust those tests to take a possible call of Reset() into account, but it would take away part of their meaning - in particular, that after regaining focus in d3d9 (non-ex) the application has to call Reset and gets D3DERR_DEVICENOTRESET otherwise. That fact is more important than what kind of message filtering does or does not happen during focus regain.
On Windows, the messages generated seem to be a random side effect of SetForegroundWindow itself. It also happens in the D3DCREATE_NOWINDOWCHANGES, although less often than in the case where d3d9 manipulates the device window. Flags are 0x1803 (SWP_NOCLIENTMOVE | SWP_NOCLIENTSIZE | SWP_NOSIZE | SWP_NOMOVE), but absent SWP_NOZORDER | SWP_NOACTIVATE, suggesting to me that the Z order was changed. See https://testbot.winehq.org/JobDetails.pl?Key=158396#k302 w8adm, w864 where it didn't happen and w8 for a case where it happened on i=1.
I'll ponder this a bit, run a few more experiments and see. The two options I see are removing the test, or moving the WINDOWPOSCHANGED part in between the SetForegroundWindow and flush_events() + making the broken() on Windows stricter - test WINDOWPOS.flags for NOSIZE | NOMOVE or somesuch.