From a223b6668cf234506c72fe73e87b8c6972e6a085 Mon Sep 17 00:00:00 2001
From: Vito Caputo <vcaputo@gnugeneration.com>
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(+)
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