On Mon Sep 8 15:02:52 2025 +0000, Rémi Bernon wrote:
The state change is done asynchronously on purpose. If we're not tracking WM state changes correctly we should debug and fix that. Restoring the synchronous processing is not really going to fix the issue, but rather hide it because it will discard the pending events by forcing the win32 state to change earlier.
The whole problem lies in the change of rcNormalRect in win32u/window.c in the NtUserGetWindowPlacement function. When the mode is changed in the first ConfigureNotify request with the send_event=FALSE parameter, the win->normal_rect = win->rects.window is changed, and in the next ConfigureNotify request with the send_event=TRUE parameter, the SC_RESTORE flag is received. In the NtUserGetWindowPlacement function, the win->normal_rect dimensions correspond to the size of the entire screen, while the win->rects.window dimensions correspond to the correct window dimensions in windowed mode. That is, there is a certain desynchronization in the process of changing the window mode.
I had the idea to add a flag that would track the type of event (the Send_event flag) and change the logic in the NtUserGetWindowPlacement function accordingly.
Due to the asynchronous execution of the request, incorrect processing occurs