Yes, that appears to be the same issue.
The reason the chat window is appearing on all desktops is that the window manager doesn't appear to be managing it. That's why the parent is the desktop and not i3. We are not setting override-redirect so that's unusual, as the window manager should have decided to manage it. As we don't see this behavior on Unity it seems like i3 is having some kind of problem.
Are you saying the chat window is visible while in the Withdrawn state? That shouldn't happen according to ICCCM.
The problem also seems to appear in, in addition to i3, in xmonad and awesomewm. Yes, the chat window is in the withdrawn state:
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified minimum size: 396 by 351
program specified maximum size: 32767 by 32767
WM_STATE(WM_STATE):
window state: Withdrawn
icon window: 0x0
WM_NAME(UTF8_STRING) = "Someone - Chat"
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Iconic State.
_NET_WM_ICON(CARDINAL) = Icon (48 x 48): [icon removed for space]
_WIN_HINTS(_WIN_HINTS) = 0x0
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0
WM_CLASS(STRING) = "Steam", "Steam"
The Withdrawn state must be a side effect of the window manager deciding not to manage the window. That's the heart of the problem, and I'm not sure why it's happening.
I'm looking a little further into this problem, i3 is aware that something odd is going on
26/01/13 19:59:31 - ERROR: Clicked into unknown window?!
26/01/13 19:59:31 - ERROR: Clicked into unknown window?!
26/01/13 19:59:32 - ERROR: Clicked into unknown window?!
26/01/13 19:59:32 - ERROR: Clicked into unknown window?!
I'll edit this post with some more information when I look through i3's source later.
The chat window behaves very strangely. When i3 is restarted in place, it ends up in a strange state in which the window is only drawn when the main steam window is over the top of it.
In addition, I've found a reproducible set of actions that do strange and unintuitive things eventually actually fixing the problems with the chat window:
From the C source concerning in-place restarts:
/* What follows is a fugly consequence of X11 protocol race conditions like
* the following: In an i3 in-place restart, i3 will reparent all windows
* to the root window, then exec() itself. In the new process, it calls
* manage_existing_windows. However, in case any application sent a
* generated UnmapNotify message to the WM (as GIMP does), this message
* will be handled by i3 *after* managing the window, thus i3 thinks the
* window just closed itself. In reality, the message was sent in the time
* period where i3 wasn’t running yet.
*
* To prevent this, we grab the server (disables processing of any other
* connections), then discard all pending events (since we didn’t do
* anything, there cannot be any meaningful responses), then ungrab the
* server. */
I can't really draw much from this, other than the fact that there is a bug that was introduced in the last update that changed how a chat window was opened to one that seems to disagree with most window managers.
Updated the last post with a workaround that fixes the problems until Steam is restarted.
Nothing extracted yet.
When I click on a name in my friends list, the steam chat window comes up for that person and focuses the window so I can type. The window cannot be focused (in my window manager, windows are focused on hover). In addition, the window persists across all desktops. Buttons on the window function as normal, so does the textarea.
Assuming it was hinting, I ran
xwininfo -allon the main steam window, the friends window and the offending chat window to see the difference using diff3:Other than the given difference between window position sizes, titles, geometry, colourmap and parent that is expected, there is also this difference, which is only in the chat window.
This particular problem seems to have happened to Mathematica before. I looked around for programs that can start in iconic mode– xterm has the -iconic flag, it does have the flags just as the chat window does when it starts, but it still tillable, focusable etc. I did a diff between the
xwininfo -alloutput of the steam Friends window, the Chat window andxterm -iconicto see why.diff3 chatWindow xterm friends | sed -e 's/^1/Chat Window/g' -e 's/^2/Xterm/g' -e 's/^3/Friends/g'I can't see any particular reason in the second diff that stands out from the other two for xterm other than the known process id, maybe someone else can tell.
I followed up with an xprop- only the offending chat window has the withdrawn state, meaning the window manager has refused to make the transition to the normal state for some reason, perhaps the diffs can help, there is also a stackoverflow answer talking about this.
Window state is set to "withdrawn" only for the offending chat window; the iconic prop window and the main steam window are set to normal.