https://bugs.winehq.org/show_bug.cgi?id=45690
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
--- Comment #1 from Vincent Povirk madewokherd@gmail.com --- I don't see how we can fix this on our end. As soon as WS_MINIMIZE is set, the Windows program expects its window to be minimized and not receive any input or expose events. If we wait for the WM to change our window state, we would be waiting forever.
Here's our WM_STATE-handling code: https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winex11.drv/event.c#l...
If a window is created minimized, it looks like we'll ignore the first WM_STATE change notification to work around another WM quirk.
Other than that, I don't see why there would be a race condition when the WM sets WM_STATE from normal to normal. It's possible there's a race condition on the win32 side (in wine or the application). A +win,+x11drv log might shed more light on this.