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 Ubuntu Touch seeded packages, which is subscribed to unity in Ubuntu. 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp