Don't move floating windows to the top with focus_follows_mouse

[Eyenseo]

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:

Video

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.

[Kommynct]

Yes please, this is incredibly annoying.

[Kommynct]

Yes please, this is incredibly annoying.

[orestisf1993]

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.

[orestisf1993]

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.

[zengargoyle]

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.

[zengargoyle]

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.

[tnnn]

I do agree with @orestisf1993 suggestion to make rising focused floating windows a configurable option. As a default (with focus_follows_mouse) it is highly confusing - i.e. it took me a while to notice that I haven't accidentally closed my 'open file' dialog but it simply dived under the splash screen.

[tnnn]

I do agree with @orestisf1993 suggestion to make rising focused floating windows a configurable option. As a default (with focus_follows_mouse) it is highly confusing - i.e. it took me a while to notice that I haven't accidentally closed my 'open file' dialog but it simply dived under the splash screen.

[Airblader]

It should definitely not be a configuration. It's a detail decision not worthy of a directive in any case, but it's also regarding floating windows which are kept intentionally simple.

If we cannot make this work in a satisfying way with what we have already we should probably just revert.

[Airblader]

It should definitely not be a configuration. It's a detail decision not worthy of a directive in any case, but it's also regarding floating windows which are kept intentionally simple.

If we cannot make this work in a satisfying way with what we have already we should probably just revert.

[orestisf1993]

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.

[orestisf1993]

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.

[tnnn]

@orestisf1993 Oops, sorry - I've incorrectly assumed that raise_floating is a configurable flag and your commit was just a work in progress. Probably too much coding for today :)

Anyway if we can restrict this 'floating rise' mechanism from being triggered by focus from focus_follows_mouse that is good enough for me.

[tnnn]

@orestisf1993 Oops, sorry - I've incorrectly assumed that raise_floating is a configurable flag and your commit was just a work in progress. Probably too much coding for today :)

Anyway if we can restrict this 'floating rise' mechanism from being triggered by focus from focus_follows_mouse that is good enough for me.

[alindt]

+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.

[alindt]

+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.

[carrotIndustries]

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.

[carrotIndustries]

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.

[jouty]

+1 for revert or be an configurable option.

[jouty]

+1 for revert or be an configurable option.

[Airblader]

Let's please keep this thread to comments that actually progress the conversation. If you want to +1 the issue then use the +1 button for it. That way we don't clutter the thread and we don't spam notification emails to everyone.

[Airblader]

Let's please keep this thread to comments that actually progress the conversation. If you want to +1 the issue then use the +1 button for it. That way we don't clutter the thread and we don't spam notification emails to everyone.

[imbecil]

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 ...)

[imbecil]

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 ...)

[Eyenseo]

@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.

[Eyenseo]

@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.

[stapelberg]

For interested parties in this bug: distinguishing between programmatic focus and focus_follows_mouse-triggered focus changes, as #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.

[stapelberg]

For interested parties in this bug: distinguishing between programmatic focus and focus_follows_mouse-triggered focus changes, as #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.

[i336]

For anybody who critically needs this and coincidentally happens to stumble on this new fix (I literally just went bug-hunting, immediately found this thread, then to my great surprise discovered the fix committed yesterday!) and wants to immediately use it:

$ git clone https://github.com/orestisf1993/i3
$ git checkout 683677af1b034eb9eebc2ee9d78a4490b99a4130
$ autoreconf ......

Thanks so much for the fixes!

[i336]

For anybody who critically needs this and coincidentally happens to stumble on this new fix (I literally just went bug-hunting, immediately found this thread, then to my great surprise discovered the fix committed yesterday!) and wants to immediately use it:

$ git clone https://github.com/orestisf1993/i3
$ git checkout 683677af1b034eb9eebc2ee9d78a4490b99a4130
$ autoreconf ......

Thanks so much for the fixes!

[carrotIndustries]

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?

[carrotIndustries]

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?

[orestisf1993]

Because this is the intended behaviour, albeit suboptimal in this case.

[orestisf1993]

Because this is the intended behaviour, albeit suboptimal in this case.

[edrex]

Yay, i just found this issue while searching for a solution, fixed 5 days ago

[edrex]

Yay, i just found this issue while searching for a solution, fixed 5 days ago

[kevinclevenger]

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.

[kevinclevenger]

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.

[orestisf1993]

This happens when the workspace is shown. To easily reproduce:

1. Open 2 floating windows
2. Focus (with focus_follows_mouse) the one behind
3. Move the mouse to the other workspace
4. Move the mouse inside the previous workspace (without it even touching a window)

[orestisf1993]

This happens when the workspace is shown. To easily reproduce:

1. Open 2 floating windows
2. Focus (with focus_follows_mouse) the one behind
3. Move the mouse to the other workspace
4. Move the mouse inside the previous workspace (without it even touching a window)