On Tue Apr 28 10:30:20 2026 +0000, Rémi Bernon wrote:
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. Ah yeah I think using the foreground window thread mitigates race conditions with foreground window changes coming from the application. The desktop thread might otherwise change foreground while some other changes is already happening... or something like that.
For the restoration issue and concurrent activation, maybe we can delay any SC_RESTORE command until the window has been made foreground by the previous foreground window. Avoiding the NtUserActivateWindow as well, which would then become unnecessary? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10725#note_137952