i3: Don't move floating windows to the top with focus_follows_mouse
Output of i3 --moreversion 2>&- || i3 --version:
Binary i3 version: 4.14.1 (2017-09-24) © 2009 Michael Stapelberg and contributors
Running i3 version: 4.14.1 (2017-09-24) (pid 1411)abort…)
Loaded i3 config: /home/eyenseo/.config/i3/config (Last modified: Mon 25 Sep 2017 15:07:42 CEST, 114 seconds ago)
The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3
URL to a logfile as per https://i3wm.org/docs/debugging.html: Not needed.
What I did:
Had a small floating window over a big floating window, moved the mouse to copy text and then moved the mouse back to the small window.
What I saw: After the mouse was back over the small window I saw the big window as the focus was moved to it and thus it was moved to the top.
What I expected instead: The small window as I did not change the focus.
This should not be the default behavior - I had similar issues where the mouse mealy touched the big window because I was overshooting the small one, it is inconvenient enough that I use focus_follows_mouse no at the moment.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 43
- Comments: 22 (10 by maintainers)
Commits related to this issue
- Don't raise floating windows when focused because of focus_follows_mouse Fixes #2990 — committed to orestisfl/i3 by orestisfl 7 years ago
- Don't raise floating windows when focused because of focus_follows_mouse Fixes #2990 — committed to orestisfl/i3 by orestisfl 7 years ago
- Raise floating window to top when it gets focus Applied for: 1. '[...] focus' for a floating container raises it to the top. 2. Focusing a window through a focus event raises it to the top. Fixes #2... — committed to i3/i3 by orestisfl 7 years ago
- Don't raise floating windows when focused because of focus_follows_mouse Fixes #2990. — committed to orestisfl/i3 by orestisfl 7 years ago
- Don't raise floating windows when focused because of focus_follows_mouse Fixes #2990. — committed to orestisfl/i3 by orestisfl 7 years ago
- Don't raise floating windows when focused because of focus_follows_mouse Fixes #2990 — committed to jolange/i3 by orestisfl 7 years ago
- Don't raise floating windows when focused because of focus_follows_mouse Fixes #2990 — committed to jolange/i3 by orestisfl 7 years ago
- Don't raise floating windows when focused because of focus_follows_mouse Fixes #2990. — committed to orestisfl/i3 by orestisfl 7 years ago
- Don't raise floating windows when workspace is shown From comment: https://github.com/i3/i3/issues/2990#issuecomment-368345169 To easily reproduce: 1. Open 2 floating windows 2. Focus (with `focus_f... — committed to orestisfl/i3 by orestisfl 6 years ago
Yes please, this is incredibly annoying.
+1 for fixing/reverting this behaviour!.. Or at least make it configurable. I went back to 4.14 as this is a huge change in my workflow.
+1 for revert or be an configurable option.
Came here to say the same thing. All of the sudden floating windows ‘pop to the top’ when they get focus and it’s extremely annoying. Totally borked my longtime workflow on my one screen with overlapping floating windows. Now I can’t type into a window without it popping up and covering up the window I need to see while typing into the underneath window. Old historical workflow that’s not easily suited to pure tiling layout for various reasons.
Definitely needs a config option to turn it off. Had to go back to 4.14 for now.
IMO this should be a bug, not an enhancement since the current behavior has some serious usability issues: Open a floating file browser window, and try to overwrite a file, so another floating dialog (Overwrite this file? Yes/No/Cancel) will pop up. Now move your mouse outside of the file browser window and back in again. Boom, the floating yes/no/cancel dialog just got obscured by the file browser. One now has to drag the file browser aside to get hold of the confirmation dialog. How can this not be a bug?
For interested parties in this bug: distinguishing between programmatic focus and focus_follows_mouse-triggered focus changes, as https://github.com/i3/i3/pull/2998 implements, seems like the best option to me, so we’ll pursue that. I did an initial review of the PR, so hopefully we’ll arrive at an implementation which works soon.
IMO it’s a reasonable default is to not raise windows focused because of
focus_follows_mouse yes. The user can click them to move the to the top.I have a draft solution in https://github.com/orestisf1993/i3/tree/issue-2990.
Or, at least respect floating containers parent/child relationship, so a floating modal window doesn’t get buried beneath its also floating parent window. This left me confused some times since I was wondering where my modal was gone and why the parent wasn’t responding.
Because this is the intended behaviour, albeit suboptimal in this case.
@imbecil I don’t think this is mutual exclusive. #2572 seems to be about that there is no change at all in the display / layer ordering. This is not good as pointed out in that issue. This issue is about the change of display order / layering without direct interaction with a window -> a mouse hover is enough to change the ordering. This is not good as pointed out in this issue.
There doesn’t have to be an option to configure it / disable it completely. I believe that is very reasonable to have the active, floating window on top. The only thing that has to change is that hovering should not change the ordering, even though the window is focused.
Considering this issue and opposite issue 2572, the right way to go is make this a configurable option, IMHO. Apparently, there are two type of user needs …
(Personally, I’m highly unhappy with this auto-rise-on-focus … so much unhappy that I reversed back to 4.14.)
(Sorry for the noise …)
An alternative is to use the Ubuntu repository as detailed on the repositories page. If your configuration is ignored after upgrade, maybe
rm ~/.config/i3/configso that it finds your old~/.i3/configfirst.With floating windows this issue still manifests with multiple screens (i.e., left + right in my case). For example, if I have a few floating windows open on the left, focus a window on the right, then slide the mouse to the left it will randomly pull one of the windows on the left to the front.
The behavior looks to be random, and happens going either direction. If I slide the mouse back and forth between right and left random windows on either screen will move to the front (if there’s a pattern or focus order I’m not seeing it). Sometimes there’s no effect on the focus of the windows. Sometimes it’s the second or third pass of the mouse between screens that will raise a random window.
Yay, i just found this issue while searching for a solution, fixed 5 days ago
I am sorry but I didn’t mean a configurable option. I think the change is trivial without the need to revert. I’ll PR my branch tomorrow.