https://bugs.winehq.org/show_bug.cgi?id=45690 Vincent Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd(a)gmail.com --- Comment #1 from Vincent Povirk <madewokherd(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.