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

1 files changed, 12 insertions, 5 deletions

diff --git a/src/fluxbox.cc b/src/fluxbox.cc
index 19a0daa..3d75b31 100644
--- a/src/fluxbox.cc
+++ b/src/fluxbox.cc
@@ -900,13 +900,13 @@ void Fluxbox::handleButtonEvent(XButtonEvent &be) {
 
 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 @@ void Fluxbox::handleUnmapNotify(XUnmapEvent &ue) {
                 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());
     }
 
 }