https://bugs.winehq.org/show_bug.cgi?id=45690
--- Comment #2 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Vincent Povirk from comment #1)
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#l1214
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.
Please add +event to the proposed debug flags to make the log slightly more verbose.