`insertPosition` misfires if a dock is started

[geekosaur]

Problem Description

In the case where a dock window is started, its window will be doIgnored instead of being placed in the StackSet. An insertPosition later in the manageHook will then use the wrong window, leading to behavior such as insertPosition Below Newer switching focus to the previously focused window. This probably also happens with other windows that are doIgnored in the manageHook. It may also happen if the new window is doShifted.

I think the only way to guard against this is for insertPosition to verify that the focused window on the current workspace is the same as that available via ask on the Query, and to refuse to operate otherwise.

Steps to Reproduce

Launch an xmonad session with the configuration file below, then restart it such that the status bar also restarts. If using xmobar, it must be set to not override_redirect; the example here uses polybar.

Configuration File

Please include the smallest full configuration file that reproduces the problem you are experiencing:

module Main (main) where

import XMonad
import XMonad.Hooks.InsertPosition

main :: IO ()
main = xmonad $ docks def {
  startupHook = spawn "polybar",
  manageHook = insertPosition Below Newer <+> manageHook def
}

Checklist

• [x] I've read CONTRIBUTING.md

• I tested my configuration

  • [x] With xmonad version 0.17.0
  • [x] With xmonad-contrib version 0.17.0

[geekosaur]

It looks like insertPosition already tries to deal with this via viewingWs. I'm not sure why it fails, unless it's because docks fires too late and therefore the window is placed only to be removed. This may be a downside of the docks combinator.

[geekosaur]

The more I think about this, the more likely it seems. It also explains why the symptom looks like it's behaving as Older: when docks doIgnores the dock that got inserted Below, the previously focused window slides into its spot in the Stack and gets the focus.

[slotThe]

Some relevant IRC conversation:

<geekosaur> the documentation for it makes it clear what ordering to use, and if you consider what it does you really do need to order it properly relative to things like doShift or doIgnore <geekosaur> it has code to deal with this, but that code is useless if the shift or ignore, etc. happens after the insertPosition <geekosaur> there is no way for it to retroactively clean up the Stack if you do something after it takes effect <geekosaur> this may argue for it being a combinator so it can always insert itself leftmost (remember, composition associates to the right), but docks would still have to insert itself rightmost to not comflict <Solid> mh, I wonder if that would break anything <geekosaur> I doubt it since after doIgnore you can't do anything anyway and arguably doing something before docks is buggy behavior <Solid> sounds about right

[etherbiswas]

Looks like this got Solved!

[etherbiswas]

Solution for Polybar is to; In

[bar/main]

override-redirect = true

[geekosaur]

Yes, that would get it doIgnored automatically and the manageHook never gets run on it, sidestepping the bug. I still think we should try to make docks and insertPosition interact sanely, though.

[slotThe]

So it should really just be a matter of changing the ordering in docks (and possibly having a combinator for insertPosition), right?

[geekosaur]

I think so, yes.