xevent: implicitly manage window in MapNotify handler

Sometimes `mplayer -fs` would result in an unmanaged window.  It seems to be
due to an unexpected ordering of events on the window:

create notify 0x1000001
creating 0x1000001
map request 0x1000001
managing 0x1000001
configure request 0x1000001
unmap notify 0x1000001 from configure 0
unmanaging 0x1000001
configure notify 0x1000001
map notify 0x1000001    <----- this happens after the window has been unmanaged!
configure notify 0x1000001
configure request 0x1000001
configure request 0x1000001
configure request 0x1000001
configure request 0x1000001
configure notify 0x1000001

So in handling MapNotify, if the window is !managed && !override_redirect,
manage it.

This is confirmed to fix the occasionally unmanaged `mplayer -fs` window.

1 files changed, 10 insertions, 0 deletions

diff --git a/src/xevent.c b/src/xevent.c
index 1955ee3..3af104d 100644
--- a/src/xevent.c
+++ b/src/xevent.c
@@ -147,6 +147,16 @@ void vwm_xevent_handle_map_notify(vwm_t *vwm, XMapEvent *ev)
 	vwm_xwindow_t	*xwin;
 
 	if ((xwin = vwm_xwin_lookup(vwm, ev->window))) {
+
+		/* XXX: in some circumstances (randomly mplayer -fs) it we see an event sequence for a window like:
+		 * create_notify->map_request (manage)->configure_request->unmap_notify (unmanage)->configure_notify->map_notify (unmanaged!)
+		 * which unless the window's an override_redirect is incorrect.
+		 * So implicitly manage the window if it's not managed and !override_redirect, since it's now mapped.
+		 */
+		if (!xwin->managed && !xwin->attrs.override_redirect) {
+			xwin->managed = vwm_win_manage_xwin(vwm, xwin);
+		}
+
 		if (xwin->managed && xwin->managed->mapping) {
 			VWM_TRACE("swallowed vwm-induced MapNotify");
 			xwin->managed->mapping = 0;