Subject: FVWM: Bug: fvwm failing to unmap window sometimes

From: Grant McDorman <[email-masked]>
Date: Tue, 26 Nov 1996 09:51:50 -0500 (EST)

I have discovered, and patched, a bug in 2.0.43.

If a Motif client quickly maps and then immediately unmaps a window, the events sent
are:
 client:   MapRequest
           synthetic UnmapNotify with selecting window ('event') equal to the root
 fvwm:     Map (as per MapRequest)
           synthetic UnmapNotify ignored because 'event' field (selecting window)
                not equal to 'window' (window being unmapped)

The result is typically a blank window; moreover, as far as the application is
concerned this window isn't there.

Comments and code in events.c appear to be checking for this synthetic event;
however, because of the immediately preceeding 'if' statement the code in
question will never get executed:

void HandleUnmapNotify()
{
  int dstx, dsty;
  Window dumwin;
  XEvent dummy;
  extern FvwmWindow *colormap_win;

  if(Event.xunmap.event != Event.xunmap.window)
    return;
  /*
   * The July 27, 1988 ICCCM spec states that a client wishing to switch
   * to WithdrawnState should send a synthetic UnmapNotify with the
   * event field set to (pseudo-)root, in case the window is already
   * unmapped (which is the case for fvwm for IconicState).  Unfortunately,
   * we looked for the FvwmContext using that field, so try the window
   * field also.
   */
  if (!Tmp_win)
    {
      Event.xany.window = Event.xunmap.window;
      if (XFindContext(dpy, Event.xany.window,
                       FvwmContext, (caddr_t *)&Tmp_win) == XCNOENT)
        Tmp_win = NULL;
    }

The obvious quick fix is to remove the if statement and Unmap() the window.
However, presumably the if statement is there for some reason; so my patch
changes the if statement to return if the 'event' and 'window' fields don't
match AND the 'event' field is not the root window, or the event is not
synthetic (send_event is false).

The patch is attached.

Grant McDorman <[email-masked]>
ISG Technologies, Inc.  http://www.isgtec.com
Mississauga, Ontario, Canada

---

From: Jamie Sparks <[email-masked]>
Date: Tue, 26 Nov 1996 10:39:43 -0500 (EST)

I realize this is a moron question, but I fit the bill, so...

How does one startup fvwm upon login?  An entry in the ~/.xinitrc file?

jamie 

*** events.c.orig	Mon May 27 15:33:26 1996
--- events.c	Mon Nov 25 11:48:11 1996
***************
*** 872,880 ****
    Window dumwin;
    XEvent dummy;
    extern FvwmWindow *colormap_win;
  
!   if(Event.xunmap.event != Event.xunmap.window)
!     return;
    /*
     * The July 27, 1988 ICCCM spec states that a client wishing to switch
     * to WithdrawnState should send a synthetic UnmapNotify with the
--- 872,887 ----
    Window dumwin;
    XEvent dummy;
    extern FvwmWindow *colormap_win;
+   int    weMustUnmap;
  
!   /*
!    * Don't ignore events as described below.
!    */
!   if(Event.xunmap.event != Event.xunmap.window && 
!      (Event.xunmap.event != Scr.Root || !Event.xunmap.send_event) )
!     {
!       return;
!     }
    /*
     * The July 27, 1988 ICCCM spec states that a client wishing to switch
     * to WithdrawnState should send a synthetic UnmapNotify with the
***************
*** 883,891 ****
--- 890,900 ----
     * we looked for the FvwmContext using that field, so try the window
     * field also.
     */
+   weMustUnmap = 0;
    if (!Tmp_win)
      {
        Event.xany.window = Event.xunmap.window;
+       weMustUnmap = 1;
        if (XFindContext(dpy, Event.xany.window,
  		       FvwmContext, (caddr_t *)&Tmp_win) == XCNOENT)
  	Tmp_win = NULL;
***************
*** 893,898 ****
--- 902,910 ----
    
    if(!Tmp_win)
      return;
+ 
+   if(weMustUnmap)
+     XUnmapWindow(dpy, Event.xunmap.window);
  
    if(Tmp_win ==  Scr.Hilite)
      Scr.Hilite = NULL;

---

From: Bob Woodside <[email-masked]>
Date: Tue, 26 Nov 1996 23:45:57 -0500 (EST)

Grant  --

    Thanks! You've found the missing piece I've been overlooking! 

GM>>  If a Motif client quickly maps and then immediately unmaps a window...

    The problem is not limited to Motif apps. It also shows up with certain
Tk apps (well, we know of one, anyway) that use the TkSteal extension to
reparent an xterm window into a Tk frame. This was reported a few weeks
back by Michael Schumacher <[email-masked]>. It is due to the same
oversight you've found.

    I sent Chuck a tentative patch that works for the reparenting case, but
that I was never comfortable with, because it doesn't catch the synthetic 
Unmap here, but detects the problem later, when we get the MapNotify and can
see that the parent has changed.

    ***  Chuck:  I have tested Grant's changed Unmap logic against Tgdb,
and it does clear up their reparent problem as well. This is clearly the
right place to detect the condition, and has broader applicability. 
Feel free to discard my version.

GM>>  The obvious quick fix...presumably the if statement is there for some
GM>>  reason...

    Yup. Although removing it makes the code look superficially more like 
version 1's handling, significant changes have been made in this area (I'm
not familiar with their history.) Removing the if produces decidedly 
unpleasant results.

    Thanks again!
    Bob

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Grant McDorman <[email-masked]>
Date: Wed, 27 Nov 1996 10:55:46 -0500 (EST)

>     Thanks! You've found the missing piece I've been overlooking! 

You're welcome.

> Tk apps...

I suspected that other applications would have the same problem; however,
since I have only observed - and tested - this with Motif, I limited my
comments to Motif.