Unity does not send UnmapNotify event when window is iconified

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)