http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #25 from Alex Villacís Lasso a_villacis@palosanto.com 2008-03-31 12:15:33 --- Created an attachment (id=11769) --> (http://bugs.winehq.org/attachment.cgi?id=11769) Workaround for issuing of PropertyNotify after MapNotify
The root cause of the bug is that dlls/winex11.drv/event.c calls get_window_wm_state() to get the state of the window (which could be NormalState or IconicState for the purposes of this bug) in X11DRV_MapNotify(), but at the moment it does, the window has not yet received the notification that the property has changed, so it sees IconicState even when the window is being restored.
As seen in the attached logs:
trace:event:call_event_handler MapNotify for hwnd/window 0x1002e/4c00007 trace:x11drv:X11DRV_MapNotify win 0x1002e/4c00007 ignoring since state=3 ... trace:event:call_event_handler PropertyNotify for hwnd/window 0x1002e/4c00007 trace:event:EVENT_PropertyNotify 0x1002e/4c00007: new WM_STATE 1
It seems that (at least in Metacity) there is no guarantee that the window state will no longer change when MapNotify is received. It can be any value (IconicState or NormalState) by the time the app gets around to process the event. Here the state changed *after* the MapNotify was received. The handler decided to ignore the event, and when the PropertyNotify was received, it did nothing.
BTW, the WM can choose to change the value *before* MapNotify, even when the PropertyNotify is issued *after* MapNotify. In that case the app is restored normally. The typical race condition. I don't know whether this describes incorrect WM behavior, but a workaround is needed for it.
The attached patch seems to fix this issue for me. It issues X11DRV_MapNotify when it detects that the window is still marked as iconic on a transition from IconicState to NormalState. Please comment on this.
Patch also sent to wine-patches.