gnome-shell with focus-mode=mouse behaves wrongly when alt-tabbing

[Robin Sheat]

I have set gnome to "focus on hover", i.e. focus follows mouse. If I alt-tab to bring a window to the front but the mouse is over another window, then the hovered-over window will reclaim focus and the window I raised will typically get covered up again.

In previous gnome versions, if I explicitly focussed a window via keyboard shortcuts, it remained focussed and I think this is the preferred behaviour.

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: gnome-shell 42.0-2ubuntu1
ProcVersionSignature: Ubuntu 5.15.0-25.25-generic 5.15.30
Uname: Linux 5.15.0-25-generic x86_64
ApportVersion: 2.20.11-0ubuntu82
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Wed Apr 20 11:35:20 2022
DisplayManager: gdm3
InstallationDate: Installed on 2022-03-17 (33 days ago)
InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20220313)
RebootRequiredPkgs: Error: path contained symlinks.
RelatedPackageVersions: mutter-common 42.0-3ubuntu2
SourcePackage: gnome-shell
UpgradeStatus: No upgrade log present (probably fresh install)

[Daniel van Vugt (vanvugt)]

Would this be the same issue?

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5410

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Robin Sheat (eythian)]

Sorry, didn't see the reply with the upstream link. It seems different to me, I haven't had any issues (that I've noticed) with invisible windows.

I've attached a screen recording. In this, I have terminal in the foreground and alt-tab to settings. Because the mouse is outside the settings window (i.e., still over terminal), terminal gets pulled almost immediately to the front again.

[BloodyIron (bloodyiron)]

I don't know if it's the same situation for me, but it might be.

On my work laptop I recently upgraded from Ubuntu 20.04 to 22.04, and the mouse focus follow function (or whatever it's called) has changed in this LTS upgrade. For me this is specifically when I close an application/window.

I have it set so focus automatically switches to where the mouse is over top, but to NOT bring any window forward (over top of others) when the focus changes, which is the desired state.

Let's say I have on one monitor Vivaldi (browser) maximised, and I have two text editor windows overlapping each other but are only windows that take up a portion of the screen.

Text Editor 1 is "on top" of Text Editor 2, and both of these Text Editor windows are "on top" of Vivaldi, in terms of the stack of view (or whatever it is called).

On Ubuntu 20.04:
If I were to close Text Editor 1, then Text Editor 2 would be on top, and if my mouse is over top of it Text Editor 2 would have focus, and still be on top of Vivaldi. If my mouse is not over top of Text Editor 2 after closing Text Editor 1, then Text Editor 2 may not be focused, however it is _still_ over top of Vivaldi and Text Editor 2 is still visible. This is the desired outcome.

On Ubuntu 22.04
If I were to close Text Editor 1, then Text Editor 2 would immediately be moved behind Vivaldi, unless my mouse was over top of Text Editor 2 when closing Text Editor 1, which is often not the case. This is _not_ the desired outcome.

To put it another way, it looks like when closing a window the check related to mouse focus immediately is performed, however in 22.04 it brings whatever window it is hovering over to the very front, which is not desired nor how it is configured to behave. Again, in 20.04 this change of window stacking did not happen with the exact same settings, and it happens in 22.04.

I rely on focus shifting tied to my mouse (without windows being pulled forward) as a key part of my high-performance workflow. So this change in outcome actually makes my workflow less efficient as I need to bring one or multiple windows back in-front when this forces windows behind others in ways that it shouldn't.

I'm unsure if this is related to the original bug, but for me this really does need to be fixed.

[johnnynyquist (johnnynyquist)]

FYI, a workaround is to run Gnome on Xorg (select "Gnome on Xorg" from the gear menu in the bottom-right corner of the GDM password screen) instead of Gnome on Wayland. This restores the original righteous behavior designed by the X wizards of old. For me, the aggravation of not being able to use alt-tab and mouse focus together is enough to keep me in these dark ages.

[Dean Kiss (ralph-ballz)]

I can confirm i have the same issue (22.04). I have Tweaks -> Windows -> Focus on Hover set. When i close a window with GUI (click X) the window underneath (the X button) gets brought over the top of all others. I note that using Xorg or X11 is a workaround but for some reason gdm3 is breaking my DisplayLink so i'm stuck using Wayland.
A fix for this would be great, both behaviours are annnoying!
thanks

[Henry Gomersall (hgomersall)]

I'm experiencing a different effect of what I _think_ is this bug, in which if I'm using multiple virtual desktops and I switch to a different desktop, then if a window on the desktop to which I am switching happens to be under the cursor, not only will it gain focus but it will also be raised to the top.

If this is deemed to be a different bug I'm happy to open a new issue, but it seems the wayland focus-follows-mouse behaviour is a little broken.

[Jan Pfeifer (pfjan)]

Same issue here, when setting Focus Follow Mouse, but with Xorg.

I have a terminal and an editor opened. My mouse is over the terminal. I Alt+Tab to the editor, it changes focus to the editor and immediately focused back on the terminal -- effectively Alt+Tab is no longer working.

Ubuntu 22.04.2 LTS.

I do have two mouses plugged in -- in case this makes any difference, but when this happens I'm not touching them.

[BloodyIron (bloodyiron)]

So I just experienced this again on a computer different from my earlier observed situation. Different as in separate hardware, but on Ubuntu 22.04 with Wayland.

Naturally, focus-follows-mouse (or whatever the consistent term is) continues to be high value for me, and I am indeed in this case coincidentally using Wayland, and I'll probably switch to xorg/X11 once I finish typing here.

The way I was able to notice it:

1. Have multiple windows open. Steam maximised behind, two gedit windows open but not one on top of the other.
2. gedit window #1 is what I had focus of, then I open gedit window #2, steam was already opened before gedit window #1, and is behind both windows of gedit at this point.
3. close gedit window #2 by clicking the X on the window dressing
4. instead of focus going back to gedit window #1, focus goes back to steam, because it is now the application "under" my mouse, as gedit window #1 is NOT under my mouse

Now the issue isn't necessarily the focus SWITCH, but to clarify more specifically, the steam window COMES TO THE FRONT in addition to focus change, which really is an important detail, as now I can't even see gedit window #1 as steam is over top of it.

This behaviour was NOT the case for Ubuntu 20.04 (I do not recall what version of GNOME that ships with). And I just tested on x11/xorg, the bring to front part of the focus switch does NOT happen, so this is specific to Wayland usage.

I took a look at selected "fix released" ticket, and the alt ticket, for gnome, and both are not approrpiate tickets for a "fix" as not only have they actually _not_ released a fix, their nature does not involve focus-follows-mouse at all.

[BloodyIron (bloodyiron)]

For those wanting to lend their thoughts: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7107

[Ari Pollak (aripollak)]

This was fixed in Ubuntu 23.04, but then broke again with 23.10. The workaround that worked for me in 22.04 was to install https://extensions.gnome.org/extension/4673/alt-tab-move-mouse/, but that's not available for GNOME 45.

Supposedly this update to mutter fixes the issue but I haven't tested it: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258

And there's an issue open to backport to mutter 45: https://gitlab.gnome.org/GNOME/mutter/-/issues/3192