Closing separate windows leaves gap in awesome tiling window manager

[mcomella]

0) Install awesome tiling window manager 1) Open Steam 2) Click "View Friends List" on the main window when it opens 3) Close the Friends list window (closing it through the window manager or the X at the top)

Expected: The Friends list closes and the other windows expand to fill the gap Actual: The gap is left open, maintaining its window border and displaying wallpaper, as if a transparent window is there. The "Friends" window remains in the taskbar (or window bar, whatever you want to call it) for the not open Friends list. Moving focus onto the window moves it back unto the window that was selected previously. See associated image:

This has happens with several windows including:

• "View Friends List"
• Account settings (from the Friends List dropdown -> Settings & from main window, Friends -> Change Profile Name..."

This does not happen with:

• Steam - Update News (on startup)

Note that these windows cannot be reopened after they are closed - I assume that the app thinks they're still open (as does the window manager) but does not draw them properly. Steam reopened them

Additionally, the top dropdown menus seem somewhat broken after this point though there is no real definitive way to describe it as pushing it to different sections of the window manager and to the second display change the interaction pattern. Generally, the menus open but the highlight is not shown - clicking an item may or may not work - I feel like this may be an issue all of the time though (I'll file another bug if I find it to be).

There is no relevant console output.

System info: https://gist.github.com/4364008

---

EDIT: With regards to the top dropdown menus, this may be related to issue #6 as my mouse dictates window focus.

[gdrewb-valve]

Steam shows and hides windows, it doesn't always destroy and recreate them. It sounds like awesome is not handling the visibility change correctly, have you tried asking on a forum for awesome WM?

[vekin]

I am not a programmer but if I had to guess I think Steam does not handle sloppy focus well and bugs out. When this happens you lose input focus menus stop working etc.

[gdrewb-valve]

You're right that sloppy focus can cause problems (and not only for Steam) but I don't believe sloppy focus is related to the window manager not retiling when windows are unmapped.

[psychon]

On IRC I was told that this problem appears with awesome 3.4 but does not occur with awesome 3.5. The big difference between the two is that awesome 3.5 is a reparenting WM while 3.4 is non-reparenting and bans windows by unmapping them.

So I think that steam is violating ICCCM § 4.1.4, transition from normal to withdrawn state: "The client should unmap the window and follow it with a synthetic UnmapNotify event as described later in this section."

Since awesome bans windows by unmapping them, it ignores all real UnmapNotify events. Instead, it depends on the synethetic event to "do its thing". If a program skips the synthetic unmap event, I would expact exactly the behavior as outlined in this bug.

For figuring out this bug, grep your source code for "XUnmapWindow" and "XWithdrawWindow". Look closely at each match and make sure that all top-level windows get hidden via XWithdrawWindow(). You should never call XUnmapWindow() on top-level windows (e.g. the friend list). Instead use XWithdrawWindow() which does an unmap and sends a synethtic UnmapNotify to the root window. So this implements exactly the behavior required by ICCCM.

Also, I want to highlight another sentence from the same section of the ICCCM which is easy to miss, too:

When a client withdraws a window, the window manager will then update or remove the WM_STATE property as described in section 4.1.3.1. Clients that want to re-use a client window (e.g. by mapping it again or reparenting it elsewhere) after withdrawing it must wait for the withdrawal to be complete before proceeding. The preferred method for doing this is for clients to wait for the window manager to update or remove the WM_STATE property.

[gdrewb-valve]

Thanks for the info, we are only calling XUnmapWindow, we'll change it to XWithdrawWindow.

[gdrewb-valve]

The next client release will use XWithdrawWindow.