Window getting stuck in "window state: Iconic" when started alongside xmonad

[jfly]

Problem Description

I have a gui application (xclock) configured with systemd to start up as part of graphical-session.target. xmonad is configured to move this application to a specific desktop (using a manageHook with a doShift). In this setup, xclock ends up in a weird situation where it's "stuck" on my screen and stays on top of everything until I switch to the desktop xclock is on, at which point everything immediately starts behaving normally.

I captured the output of xprop on this xclock application both before and after the "fix", and I saw that the only difference between the 2 applications was the window state: when broken, the window state was "Iconic", and when working, it is "Normal":

$ diff -u /tmp/broken /tmp/working
--- /tmp/broken	2022-09-25 22:12:17.074157763 -0700
+++ /tmp/working	2022-09-25 22:12:21.694270593 -0700
@@ -1,7 +1,7 @@
 $ xprop
 _NET_WM_DESKTOP(CARDINAL) = 14
 WM_STATE(WM_STATE):
-		window state: Iconic
+		window state: Normal
        icon window: 0x0
 WM_HINTS(WM_HINTS):
        Client accepts input or input focus: True

If I remove the doShift, the problem goes away. I've tried with other applications, and can reproduce the issue, so I don't think it's application specific.

Wild guess: maybe this old TODO about scanning for WM_STATE == Iconic is relevant?

Steps to Reproduce

I am able to reproduce this with the simplified config file below + the xclock user service also below.

Unfortunately, I am not able to reproduce this in Xephyr, so perhaps there is something relevant about how I actually start xmonad (right now it's started by lightdm via some nixos generated config files that I haven't taken the time to fully understand yet).

Configuration File

xmonad.hs:

import XMonad
import XMonad.Hooks.ManageDocks

main = xmonad defaultConfig {
    manageHook = composeAll [
        className =? "XClock" --> doShift "2"
    ]
}

/etc/systemd/user/xclock.service:

[Unit]
PartOf=graphical-session.target

[Service]
ExecStart=/nix/store/8g8ic2d61dirnrpwrl4498l9hlwk8m6n-xclock-1.0.9/bin/xclock

Checklist

• I've read CONTRIBUTING.md

• I tested my configuration

  • With xmonad version 0.17.0
  • With xmonad-contrib version 0.17.0

[geekosaur]

The code after that TODO actually does what the TODO is talking about, and is referenced in the preceding loop, so I think the comment is out of date / should be removed. But if the window is marked Iconic then it shouldn't be visible (mapped). At most only the icon window should be (but we don't support icon windows, IIRC; not that this matters since icon window is 0x0 / nonexistent).

Do you have any other windows open before you trigger this by switching to workspace 2? In particular, I would be interested to know if opening and then closing a terminal either avoids the clock or overwrites it, and in the latter case if it displays properly after closing the terminal window.

[jfly]

Do you have any other windows open before you trigger this by switching to workspace 2?

I do not have any windows open before I trigger this. I'm also worried I didn't explain myself clearly: the issue occurs immediately on x11/xmonad startup, there isn't really anything I do to trigger it. Switching to workspace 2 is what fixes it.

This is really hard to explain in words, so I've made a screen recording. This recording starts just after x11/xmonad starts up. You can see that there's an xclock window sort of floating at the top right on top of polybar, and when I start a terminal, the terminal appears on top of it, but does not fix the issue with xclock. Finally, when I switch to workspace 2, you can see the problem goes away (xclock becomes a regular old tiling window).

output.mp4

[geekosaur]

Sorry, I understood that, I just phrased my response poorly. I wanted to know if the window had space reserved for it, which it sounds like it doesn't; nor is it floating since the terminal covers it. This suggests it isn't being managed until the workspace switch, which shouldn't happen.

[geekosaur]

IRC discussion about this bug (just the end which is mostly a summary)

[28 14:53:47] <geekosaur> there are no workspaces when the window is mapped; it will become the active workspace when xmonad starts. so everything should work. even if the first thing you do in the startupHook is switch workspaces, because managing is done before running the startupHook
[28 14:55:45] <geekosaur> sadly this means I need to customize ManageDebug to dump the initial manage stuff 😕
[28 14:56:25] <[Leary]> The window is mapped but belongs to no workspace until xmonad manages it. `manage` produces two functions, `g` and `f` from the managehook and it's own insertion logic respectively. But if `g` shifts the window to an invisible workspace, then `windows (g . f)` never sees the window as ever having been anywhere else.
[28 14:57:01] <[Leary]> And hence sees no need to `hide` it.
[28 14:57:17] <geekosaur> reversed, no? but yes, I see that point
[28 14:57:48] <geekosaur> that is, f would be doing the shifting
[28 14:58:02] <geekosaur> but this has worked for me before…
[28 14:58:18] <geekosaur> hm. not sure I've ever done a doShift with it though
[28 14:58:20] <[Leary]> No, `f` puts it in the current workspace, but that's transparently eliminated by the composition.
[28 14:59:00] <[Leary]> Anyway, I think `manage` needs to run `hide` in some circumstances.
[28 14:59:04] <liskin> mapM_ hide (nub (oldvisible ++ newwindows) \\ visible)
[28 14:59:11] <liskin> this should hide it though, shouldn't it?
[28 14:59:52] <liskin> it'll be in newwindows
[28 14:59:59] <liskin> but not in visible
[28 14:59:59] <[Leary]> Hmmm. You might be right.

So as far as we can tell this should work.

[geekosaur]

https://paste.tomsmeding.com/H0IVfz7w is a modified form of XMonad.Hooks.ManageDebug that can debug managing the windows that are managed when xmonad starts (the startupHook runs too late for this, so the initial state had to be changed instead). Save this as lib/XMonad/Hooks/ManageDebug.hs (lib should be in the same directory as your xmonad.hs), and change xmonad defaultConfig to xmonad $ debugManageHook defaultConfig.

[geekosaur]

Oh, actually the xmonad.hs mod should work without the custom XMonad.Hooks.ManageDebug; the change I made should only matter if using debugManageHookOn which we aren't, here.

[jfly]

Here are the logs with XMonad.Hooks.ManageDebug. I started up on workspace 1 with polybar and xclock. I then switched to workspace 2, and opened xterm. Hope this helps!

2022-09-28-xmonad-issue-422.log

[geekosaur]

Hm. According to the log, the manageHook executed correctly and moved the clock to workspace 2. But somehow the actual move didn't happen.

I have several moves via spawnOn in my own config and those happen correctly, so I'm not sure what's going on here at all.