all repos — fluxbox @ 8054e16fab822e6171a58d28bd087e5508839603

custom fork of the fluxbox windowmanager 

fix for #1087220 (Wrong handling of XWithdrawWindow)

an XWithdrawWindow unmaps a window and sends a synthetic UnmapEvent after
that. when the second UnmapEvent arrives we have to set either the WM_STATE to
WithdrawnState or delete it. i decided for deletion so its absolutly clear
its not any longer under our control
mathias mathias
commit

8054e16fab822e6171a58d28bd087e5508839603

parent

51f30a5a63c1ce233220df0f39bfccba9975698d

1 files changed, 12 insertions(+), 5 deletions(-)

jump to
M src/fluxbox.cc → src/fluxbox.cc 
@@ -900,13 +900,13 @@ }
 
 void Fluxbox::handleUnmapNotify(XUnmapEvent &ue) {
 
-
-    WinClient *winclient = 0;
-
     BScreen *screen = searchScreen(ue.event);
-
-    if ( ue.event != ue.window && (screen != 0 || !ue.send_event))
+    
+    if (ue.event != ue.window && (!screen || !ue.send_event)) {
         return;
+    }
+
+    WinClient *winclient = 0;
 
     if ((winclient = searchWindow(ue.window)) != 0) {
 

@@ -929,6 +929,13 @@ delete win;
                 win = 0;
             }
         }
+
+    // according to http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.4
+    // a XWithdrawWindow is 
+    //   1) unmapping the window (which leads to the upper branch
+    //   2) sends an synthetic unampevent (which is handled below)
+    } else if (screen && ue.send_event) {
+        XDeleteProperty(display(), ue.window, FbAtoms::instance()->getWMStateAtom());
     }
 
 }