From a223b6668cf234506c72fe73e87b8c6972e6a085 Mon Sep 17 00:00:00 2001 From: Vito Caputo Date: Mon, 19 Dec 2016 00:25:28 -0800 Subject: 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. --- src/xevent.c | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'src') 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; -- cgit v1.2.3