Fwiw I think various issues are coming from the fact that we update the Win32 state concurrently. For a given window receiving focus, and possibly getting restored, we have two different threads receiving events from X11 and possibly going to do some changes: 1) The currently foreground window thread (often the desktop if no Wine window is focused, but sometimes it is another non-minimized Wine window thread), which has the charge of tracking the host focus and which will call set_foreground_window when host active window changes. 2) Any window that gets restored, or which minimized/maximized state changes (but I think issues occur mostly when un-minimizing as it also involves activation), which is going (explicitly now but it was also the case before the revert from the SC_RESTORE command as well) to call NtUserSetActiveWindow, and to restore the window. Perhaps it would be better to try a mechanism so that we have only one thread handling both. I think the foreground thread could be in charge, but we can also consider moving everything into the desktop thread, although there is perhaps a reason I preferred the foreground thread, but I can't remember exactly. It would however be a bit tricky to detect window restorations, because right now we only track window states on their owner thread (or process) and we don't really have a global host state kept anywhere. This is an inherent issue with the distributed model we have, I'm not sure what to do about it. I think it would better to have a centralized host window integration but we're unlikely going to have that anytime soon. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10725#note_137949