New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't move floating windows to the top with focus_follows_mouse #2990

Closed
Eyenseo opened this Issue Sep 25, 2017 · 20 comments

Comments

Projects
None yet
@Eyenseo

Eyenseo commented Sep 25, 2017

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.

@i3bot i3bot added the enhancement label Sep 25, 2017

@Kommynct

This comment has been minimized.

Show comment
Hide comment
@Kommynct

Kommynct Sep 25, 2017

Yes please, this is incredibly annoying.

Kommynct commented Sep 25, 2017

Yes please, this is incredibly annoying.

orestisf1993 added a commit to orestisf1993/i3 that referenced this issue Sep 25, 2017

@orestisf1993

This comment has been minimized.

Show comment
Hide comment
@orestisf1993

orestisf1993 Sep 25, 2017

Member

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.

Member

orestisf1993 commented Sep 25, 2017

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.

@Eyenseo Eyenseo changed the title from [enhancement] Don't move floating windows to the top with focus_follows_mouse to Don't move floating windows to the top with focus_follows_mouse Sep 25, 2017

@Airblader Airblader added the 4.14 label Sep 25, 2017

@zengargoyle

This comment has been minimized.

Show comment
Hide comment
@zengargoyle

zengargoyle Sep 27, 2017

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 commented Sep 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tnnn

tnnn Sep 27, 2017

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 commented Sep 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Airblader

Airblader Sep 27, 2017

Member

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.

Member

Airblader commented Sep 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@orestisf1993

orestisf1993 Sep 27, 2017

Member

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.

Member

orestisf1993 commented Sep 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tnnn

tnnn Sep 27, 2017

@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 commented Sep 27, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@alindt

alindt Sep 30, 2017

+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 commented Sep 30, 2017

+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

This comment has been minimized.

Show comment
Hide comment
@carrotIndustries

carrotIndustries Oct 2, 2017

Contributor

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.

Contributor

carrotIndustries commented Oct 2, 2017

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.

orestisf1993 referenced this issue Oct 5, 2017

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 #2572
@jouty

This comment has been minimized.

Show comment
Hide comment
@jouty

jouty Oct 7, 2017

+1 for revert or be an configurable option.

jouty commented Oct 7, 2017

+1 for revert or be an configurable option.

@Airblader

This comment has been minimized.

Show comment
Hide comment
@Airblader

Airblader Oct 7, 2017

Member

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.

Member

Airblader commented Oct 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@imbecil

imbecil Oct 11, 2017

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 commented Oct 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Eyenseo

Eyenseo Oct 11, 2017

@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 commented Oct 11, 2017

@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 stapelberg self-assigned this Oct 24, 2017

@stapelberg

This comment has been minimized.

Show comment
Hide comment
@stapelberg

stapelberg Oct 24, 2017

Member

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.

Member

stapelberg commented Oct 24, 2017

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

This comment has been minimized.

Show comment
Hide comment
@i336

i336 Dec 7, 2017

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 commented Dec 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@carrotIndustries

carrotIndustries Jan 14, 2018

Contributor

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?

Contributor

carrotIndustries commented Jan 14, 2018

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

This comment has been minimized.

Show comment
Hide comment
@orestisf1993

orestisf1993 Jan 14, 2018

Member

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

Member

orestisf1993 commented Jan 14, 2018

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

orestisf1993 added a commit to orestisf1993/i3 that referenced this issue Jan 14, 2018

@stapelberg stapelberg closed this in #2998 Jan 14, 2018

@edrex

This comment has been minimized.

Show comment
Hide comment
@edrex

edrex Jan 19, 2018

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

edrex commented Jan 19, 2018

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

@kevinclevenger

This comment has been minimized.

Show comment
Hide comment
@kevinclevenger

kevinclevenger Feb 25, 2018

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 commented Feb 25, 2018

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 comment has been minimized.

Show comment
Hide comment
@orestisf1993

orestisf1993 Feb 26, 2018

Member

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

orestisf1993 commented Feb 26, 2018

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 added a commit to orestisf1993/i3 that referenced this issue Feb 26, 2018

Don't raise floating windows when workspace is shown
From comment:
i3#2990 (comment)

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)

BuJo added a commit to BuJo/sway that referenced this issue Sep 25, 2018

Add configuration for raising containers on focus
* New configuration option: raise_floating
  (From the discussion on i3/i3#2990)
* By default, it still raises the window on focus, otherwise it
  will raise the window on click.

@BuJo BuJo referenced this issue Sep 25, 2018

Open

raise floating #2709

BuJo added a commit to BuJo/sway that referenced this issue Sep 25, 2018

Add configuration for raising containers on focus
* New configuration option: raise_floating
  (From the discussion on i3/i3#2990)
* By default, it still raises the window on focus, otherwise it
  will raise the window on click.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment