Comment 6 for bug 1969602

Revision history for this message
BloodyIron (bloodyiron) wrote : Re: gnome-shell with "Focus on hover" behaves wrongly when alt-tabbing

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.