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
Comments
Yes please, this is incredibly annoying. |
IMO it's a reasonable default is to not raise windows focused because of I have a draft solution in https://github.com/orestisf1993/i3/tree/issue-2990. |
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. |
I do agree with @orestisf1993 suggestion to make rising focused floating windows a configurable option. As a default (with |
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. |
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 Oops, sorry - I've incorrectly assumed that Anyway if we can restrict this 'floating rise' mechanism from being triggered by focus from |
+1 for fixing/reverting this behaviour!... Or at least make it configurable. |
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. |
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
+1 for revert or be an configurable option. |
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. |
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 I don't think this is mutual exclusive. 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. |
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. |
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:
Thanks so much for the fixes! |
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? |
Because this is the intended behaviour, albeit suboptimal in this case. |
Yay, i just found this issue while searching for a solution, fixed 5 days ago |
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. |
This happens when the workspace is shown. To easily reproduce:
|
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)
For those coming here because the i3 on Ubuntu 18.04 is pretty broken (e.g. file save dialog focus problem, as mentioned above): There is no proper solution. Ubuntu 18.04 has i3 version You must compile from source, e.g. i3 version Separately: I'd also like to post this on https://www.reddit.com/r/i3wm/comments/a1rjzo/focus_but_not_to_front/ for people searching for the problem, but cannot comment there because the thread is "too old", New comments cannot be posted. Reddit with its auto-archiving is a horrible tool for a problem-solution knowledge base, because nobody can post after a solution is available. That promotes user frustration and wastes everyone's time. (CC @stapelberg) |
An alternative is to use the Ubuntu repository as detailed on the repositories page. If your configuration is ignored after upgrade, maybe |
Output of
i3 --moreversion 2>&- || i3 --version
: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.The text was updated successfully, but these errors were encountered: