https://bugs.winehq.org/show_bug.cgi?id=57569
--- Comment #4 from RĂ©mi Bernon rbernon@codeweavers.com --- Looking at the logs there's nothing obviously wrong going on and it's maybe instead some timing difference that made the behavior to change:
There's a (4,28)-(2556,1441) window that is created and initially mapped (I assume this is the game window as it is the only one that gets minimized at some point in the broken case)
Then, another window is created, mapped and made fullscreen, then quickly gets destroyed. It only briefly exists but enough time for the window manager to try giving it focus. It is shown with SW_SHOW, so it is supposed to activate, nothing wrong about that.
Still, as focus briefly changes the game window receives a FocusOut event shortly after, with a FocusIn shortly following it after the WM figured that the other window has been destroyed. From there, the two cases begin to differ:
- In the working case, we ignore the FocusOut, probably because we check whether focus is still on another Wine window or not and, by chance, this happens to be the case as the WM already decided to give focus back to the game window.
- In the broken case, the check fails, possibly because we don't block anymore waiting for map/unmap, and we check focus slightly before the WM decided to give it back. We then decide we've lost focus and apply the FocusOut even by changing the Win32 foreground window to the desktop window. This, in turn, causes the game window to lose focus on the Win32 side too, and it decides to minimize itself.