desktop-packages team mailing list archive

Thread
Date
[Bug 1502370] [NEW] Unity does not send UnmapNotify event when window is iconified

To: desktop-packages@xxxxxxxxxxxxxxxxxxx
From: David B <dburg@xxxxxxxxxxxxx>
Date: Sat, 03 Oct 2015 01:30:32 -0000
Reply-to: Bug 1502370 <1502370@xxxxxxxxxxxxxxxxxx>
Sender: bounces@xxxxxxxxxxxxx
Public bug reported:

To reproduce this bug, run "wish" in a terminal window.  Here's what I did in wish:
> wish
% wm tracing 1
% wm iconify .
WaitForMapNotify giving up on .
WaitForMapNotify finished with . (winPtr 0x1af3a50, wmPtr 0x1af3850)
% wm state .
normal
% wm deiconify .
% 

Three symptoms can be seen in the wish session:
 1. wish should not report "WaitForMapNotify giving up on ."
 2. After the "wm iconify ." command, the window disappears; however, the "wm state ." should report "iconic" instead of "normal".
 3. The "wm deiconify ." command should make the window reappear, but it does not.

I'm struggling with whether this is a Unity bug or a Tk bug.  The problem is exhibited under Unity and Gnome Shell, but does not occur under fvwm2 (I ran the test under all 3 window managers on the same system).  Under fvwm2:
 1. wish does not report "WaitForMapNotify giving up on ."
 2) The "wm state ." command correctly returns "iconic".
 3) The "wm deiconify ." command correctly makes the window reappear.

Under Gnome Shell and fvwm2, I was able to run "xtrace wish", and repeat the session to watch the X11 events (I got a SEGV when I tried this under Unity and I filed a bug).  Under Gnome Shell, the xtrace info looks like this:
    000:<:0092: 24: Request(16): InternAtom only-if-exists=false(0x00) name='WM_CHANGE_STATE'
    000:>:0092:32: Reply to InternAtom: atom=0x1dc("WM_CHANGE_STATE")
    000:<:0093: 44: Request(25): SendEvent propagate=false(0x00) destination=0x0000009b event-mask=SubstructureNotify,SubstructureRedirect ClientMessage(33) format=0x20 window=0x01800006 type=0x1dc("WM_CHANGE_STATE") data=0x03,0x00,0x00,0x00,0xf0,0x71,0xd0,0x00,0x28,0x3e,0xc4,0x00,0x00,0x00,0x00,0x00,0x06,0x00,0x80,0x01;
    000:>:0093: Event PropertyNotify(28) window=0x01800006 atom=0x185(unrecognized atom) time=0x04931165 state=NewValue(0x00)
    000:>:0093: Event PropertyNotify(28) window=0x01800006 atom=0x15c("_NET_WM_STATE") time=0x04931165 state=NewValue(0x00)
    000:<:0094: 24: Request(20): GetProperty delete=false(0x00) window=0x01800006 property=0x15c("_NET_WM_STATE") type=0x4("ATOM") long-offset=0x00000000 long-length=0x00000400
    000:>:0094:36: Reply to GetProperty: type=0x4("ATOM") bytes-after=0x00000000 data=;

Under fvwm2, the xtrace info looks like this:
    000:<:008b: 24: Request(16): InternAtom only-if-exists=false(0x00) name='WM_CHANGE_STATE'
    000:>:008b:32: Reply to InternAtom: atom=0x1b1("WM_CHANGE_STATE")
    000:<:008c: 44: Request(25): SendEvent propagate=false(0x00) destination=0x0000009b event-mask=SubstructureNotify,SubstructureRedirect ClientMessage(33) format=0x20 window=0x01c00006 type=0x1b1("WM_CHANGE_STATE") data=0x03,0x00,0x00,0x00,0xa0,0x7c,0x34,0x02,0x28,0xce,0x13,0x02,0x00,0x00,0x00,0x00,0x06,0x00,0xc0,0x01;
    000:>:008c: Event UnmapNotify(18) event=0x01c00006 window=0x01c00006 from-configure=false(0x00)
    000:>:008c: Event PropertyNotify(28) window=0x01c00006 atom=0x185(unrecognized atom) time=0x04aa349c state=NewValue(0x00)
    000:<:008d:  8: Request(10): UnmapWindow window=0x01c00005
    000:>:008d: Event PropertyNotify(28) window=0x01c00006 atom=0x15c("_NET_WM_STATE") time=0x04aa349d state=NewValue(0x00)
    000:<:008e:  4: Request(127): NoOperation 
    000:<:008f: 24: Request(20): GetProperty delete=false(0x00) window=0x01c00006 property=0x15c("_NET_WM_STATE") type=0x4("ATOM") long-offset=0x00000000 long-length=0x00000400
    000:>:008f:36: Reply to GetProperty: type=0x4("ATOM") bytes-after=0x00000000 data=;

Note that fvwm2 returns the UnmapNotify event to the client (in response
to the ClientMessage event), but Gnome Shell (and presumably Unity)
doesn't.  As a result, wish does not send the UnmapWindow request to the
window manager under Gnome Shell.

The ICCCM (section 4.1.4) says "Clients can select for StructureNotify
on their top-level windows to track transitions between Normal and
Iconic states. Receipt of a MapNotify event will indicate a transition
to the Normal state, and receipt of an UnmapNotify event will indicate a
transition to the Iconic state.

The relevant Tk code is in the tk8.6 source package
(http://packages.ubuntu.com/source/trusty/tk8.6).  At the bottom of
unix/tkUnixWm.c the TkpWmSetState() function calls XIconifyWindow(),
followed by WaitForMapNotify().  It is WaitForMapNotify() that prints
out the message that it is giving up.  There's an interesting  comment
in WaitForMapNotify() that says "There are some bizarre situations in
which the window manager can't respond or chooses not to (e.g. if we've
got a grab set it can't respond).  If this happens, then just quit."
The problem is that just quitting leaves Tk  with an incorrect
impression of the window's state.  Under fvwm2, the UnmapNotify event
causes Tk to call XUnmapWindow(), which seems to straighten things out.

As I previously said, I'm torn on whether this is a Tk bug or a
Unity/Gnome Shell bug.  Since both Unity and Gnome Shell get the same
answer, and WaitForMapNotify() says that it needs to handle the
situation where the window manager does not respond with the UnmapNotify
event, I'm inclined to think that this is a Tk bug.  However, since fvwm
exhibits the correct behavior, and the ICCCM seems to say that the
window manager should return the UnmapNotify event to the client, I
decided to file the bug against Unity.

----------------

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: unity 7.2.5+14.04.20150603-0ubuntu1
ProcVersionSignature: Ubuntu 3.16.0-50.66~14.04.1-generic 3.16.7-ckt16
Uname: Linux 3.16.0-50-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.15
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CurrentDesktop: Unity
Date: Fri Oct  2 18:57:04 2015
InstallationDate: Installed on 2015-05-11 (144 days ago)
InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150218.1)
SourcePackage: unity
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: unity (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: amd64 apport-bug trusty

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity in Ubuntu.
Matching subscriptions: dp-unity
https://bugs.launchpad.net/bugs/1502370

Title:
  Unity does not send UnmapNotify event when window is iconified

Status in unity package in Ubuntu:
  New

Bug description:
  To reproduce this bug, run "wish" in a terminal window.  Here's what I did in wish:
  > wish
  % wm tracing 1
  % wm iconify .
  WaitForMapNotify giving up on .
  WaitForMapNotify finished with . (winPtr 0x1af3a50, wmPtr 0x1af3850)
  % wm state .
  normal
  % wm deiconify .
  % 

  Three symptoms can be seen in the wish session:
   1. wish should not report "WaitForMapNotify giving up on ."
   2. After the "wm iconify ." command, the window disappears; however, the "wm state ." should report "iconic" instead of "normal".
   3. The "wm deiconify ." command should make the window reappear, but it does not.

  I'm struggling with whether this is a Unity bug or a Tk bug.  The problem is exhibited under Unity and Gnome Shell, but does not occur under fvwm2 (I ran the test under all 3 window managers on the same system).  Under fvwm2:
   1. wish does not report "WaitForMapNotify giving up on ."
   2) The "wm state ." command correctly returns "iconic".
   3) The "wm deiconify ." command correctly makes the window reappear.

  Under Gnome Shell and fvwm2, I was able to run "xtrace wish", and repeat the session to watch the X11 events (I got a SEGV when I tried this under Unity and I filed a bug).  Under Gnome Shell, the xtrace info looks like this:
      000:<:0092: 24: Request(16): InternAtom only-if-exists=false(0x00) name='WM_CHANGE_STATE'
      000:>:0092:32: Reply to InternAtom: atom=0x1dc("WM_CHANGE_STATE")
      000:<:0093: 44: Request(25): SendEvent propagate=false(0x00) destination=0x0000009b event-mask=SubstructureNotify,SubstructureRedirect ClientMessage(33) format=0x20 window=0x01800006 type=0x1dc("WM_CHANGE_STATE") data=0x03,0x00,0x00,0x00,0xf0,0x71,0xd0,0x00,0x28,0x3e,0xc4,0x00,0x00,0x00,0x00,0x00,0x06,0x00,0x80,0x01;
      000:>:0093: Event PropertyNotify(28) window=0x01800006 atom=0x185(unrecognized atom) time=0x04931165 state=NewValue(0x00)
      000:>:0093: Event PropertyNotify(28) window=0x01800006 atom=0x15c("_NET_WM_STATE") time=0x04931165 state=NewValue(0x00)
      000:<:0094: 24: Request(20): GetProperty delete=false(0x00) window=0x01800006 property=0x15c("_NET_WM_STATE") type=0x4("ATOM") long-offset=0x00000000 long-length=0x00000400
      000:>:0094:36: Reply to GetProperty: type=0x4("ATOM") bytes-after=0x00000000 data=;

  Under fvwm2, the xtrace info looks like this:
      000:<:008b: 24: Request(16): InternAtom only-if-exists=false(0x00) name='WM_CHANGE_STATE'
      000:>:008b:32: Reply to InternAtom: atom=0x1b1("WM_CHANGE_STATE")
      000:<:008c: 44: Request(25): SendEvent propagate=false(0x00) destination=0x0000009b event-mask=SubstructureNotify,SubstructureRedirect ClientMessage(33) format=0x20 window=0x01c00006 type=0x1b1("WM_CHANGE_STATE") data=0x03,0x00,0x00,0x00,0xa0,0x7c,0x34,0x02,0x28,0xce,0x13,0x02,0x00,0x00,0x00,0x00,0x06,0x00,0xc0,0x01;
      000:>:008c: Event UnmapNotify(18) event=0x01c00006 window=0x01c00006 from-configure=false(0x00)
      000:>:008c: Event PropertyNotify(28) window=0x01c00006 atom=0x185(unrecognized atom) time=0x04aa349c state=NewValue(0x00)
      000:<:008d:  8: Request(10): UnmapWindow window=0x01c00005
      000:>:008d: Event PropertyNotify(28) window=0x01c00006 atom=0x15c("_NET_WM_STATE") time=0x04aa349d state=NewValue(0x00)
      000:<:008e:  4: Request(127): NoOperation 
      000:<:008f: 24: Request(20): GetProperty delete=false(0x00) window=0x01c00006 property=0x15c("_NET_WM_STATE") type=0x4("ATOM") long-offset=0x00000000 long-length=0x00000400
      000:>:008f:36: Reply to GetProperty: type=0x4("ATOM") bytes-after=0x00000000 data=;

  Note that fvwm2 returns the UnmapNotify event to the client (in
  response to the ClientMessage event), but Gnome Shell (and presumably
  Unity) doesn't.  As a result, wish does not send the UnmapWindow
  request to the window manager under Gnome Shell.

  The ICCCM (section 4.1.4) says "Clients can select for StructureNotify
  on their top-level windows to track transitions between Normal and
  Iconic states. Receipt of a MapNotify event will indicate a transition
  to the Normal state, and receipt of an UnmapNotify event will indicate
  a transition to the Iconic state.

  The relevant Tk code is in the tk8.6 source package
  (http://packages.ubuntu.com/source/trusty/tk8.6).  At the bottom of
  unix/tkUnixWm.c the TkpWmSetState() function calls XIconifyWindow(),
  followed by WaitForMapNotify().  It is WaitForMapNotify() that prints
  out the message that it is giving up.  There's an interesting  comment
  in WaitForMapNotify() that says "There are some bizarre situations in
  which the window manager can't respond or chooses not to (e.g. if
  we've got a grab set it can't respond).  If this happens, then just
  quit."  The problem is that just quitting leaves Tk  with an incorrect
  impression of the window's state.  Under fvwm2, the UnmapNotify event
  causes Tk to call XUnmapWindow(), which seems to straighten things
  out.

  As I previously said, I'm torn on whether this is a Tk bug or a
  Unity/Gnome Shell bug.  Since both Unity and Gnome Shell get the same
  answer, and WaitForMapNotify() says that it needs to handle the
  situation where the window manager does not respond with the
  UnmapNotify event, I'm inclined to think that this is a Tk bug.
  However, since fvwm exhibits the correct behavior, and the ICCCM seems
  to say that the window manager should return the UnmapNotify event to
  the client, I decided to file the bug against Unity.

  ----------------

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: unity 7.2.5+14.04.20150603-0ubuntu1
  ProcVersionSignature: Ubuntu 3.16.0-50.66~14.04.1-generic 3.16.7-ckt16
  Uname: Linux 3.16.0-50-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.15
  Architecture: amd64
  CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
  CurrentDesktop: Unity
  Date: Fri Oct  2 18:57:04 2015
  InstallationDate: Installed on 2015-05-11 (144 days ago)
  InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150218.1)
  SourcePackage: unity
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1502370/+subscriptions