After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 739718 - Alt-Tab and focus-follows-mouse don't play well together
Alt-Tab and focus-follows-mouse don't play well together
Status: RESOLVED OBSOLETE
Product: mutter
Classification: Core
Component: wayland
3.28.x
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
: 745380 774697 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-11-06 09:54 UTC by Magnus Therning
Modified: 2021-07-05 13:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Backtrace (13.15 KB, text/plain)
2020-04-17 18:29 UTC, Phillip Wood
Details

Description Magnus Therning 2014-11-06 09:54:18 UTC
This is the behaviour I see in Gnome 3.14.1 (Archlinux) with focus-follows-mouse (and sloppy-focus too):

1. Open a Firefox, maximize it
2. Open Terminal, make it half-screen and move it right (meta-right)
3. Move mouse to the right side to ensure Terminal has focus
3. Move mouse to the left side of screen, focus follows to Firefox
4. Alt-Tab to Terminal

Expected behaviour: Terminal gains focus
Observed behaviour: focus remains in Firefox

NB: The specific apps I've written above were the ones I had open when the camel's back broke and I decided to write this report ;)  I've seen the behaviour with two Terminals, with a Terminal and Vim, Gedit and Nautilus, etc.  Also, the tiling/maximizing is not necessary, but it makes for easily reproducible steps.  Finally, I asked on #gnome and one helpful soul reported that the steps indeed reproduce the issue (thanks mgedmin).
Comment 1 Magnus Therning 2014-11-06 09:58:27 UTC
Duplicate of #725805?
Comment 2 Jonathan Kamens 2017-10-23 14:14:04 UTC
Generally speaking, when Sloppy focus is configured, Alt-Tab and Alt-` change focus to the other window temporarily but then switch it back to the window that the mouse is over. This is highly suboptimal. Pretty disappointing that this bug was reported almost three years ago and has received no attention. It's still a bug in 3.26.1.
Comment 3 Bart Snapp 2018-01-04 19:17:48 UTC
I too am unhappy with the combined behaviour of "sloppy" focus and Alt-Tab in Gnome Version 3.26.2.

Current behaviour: Windows A and B are side-by-side, with mouse over A, if Alt-Tab selects B, the focus stays with A.

Desired behaviour: Windows A and B are side-by-side, with mouse over A, if Alt-Tab selects B, the focus moves to B.
Comment 4 Brandon Kuczenski 2018-03-14 18:56:14 UTC
I too find this an annoying regression, having just switched to gnome 3 (I was a metacity holdout for many years). It's pretty clearly not application-specific.

Perhaps this could be fixed with a shell extension? I'm afraid I don't know much about such things, but I'm pretty impressed with the extensions system.
Comment 5 Florian Müllner 2018-03-21 12:30:52 UTC
(In reply to Brandon Kuczenski from comment #4)
> Perhaps this could be fixed with a shell extension?

No, this is likely an issue in the lower-level events/focus handling in mutter.

I did a quick test and could reproduce the issue in a wayland session, but got the expected behavior on Xorg - is that what everyone is seeing?
Comment 6 Jonathan Kamens 2018-03-21 12:45:23 UTC
(In reply to Florian Müllner from comment #5)
> I did a quick test and could reproduce the issue in a wayland session, but
> got the expected behavior on Xorg - is that what everyone is seeing?

That is my experience. It's one of the (numerous) reasons I switched back from Wayland to Xorg. I'm waiting for some of the kinks like this in Wayland to be ironed out before it's good enough for everyday use (at least for me).
Comment 7 Florian Müllner 2018-03-21 13:07:51 UTC
This is likely an issue in mutter then.
Comment 8 Andrew Chadwick 2018-06-11 10:41:50 UTC
Affects me too, just as in comment #5.

Lack of sloppy focus is almost a deal-breaker for me using Wayland, but sadly I have to fix bugs elsewhere which can only be reproduced under Wayland. Click-to-focus feels so very inelegant and wasteful.

There is now a duplicate of this at https://gitlab.gnome.org/GNOME/gnome-shell/issues/134 with some additional discussion.
Comment 9 Jeremy Nickurak 2019-09-09 20:02:27 UTC
It's always a little bothered me that there can be an inconsistency in the mouse being pointed at a window that's not focused in 

One workaround (not without side effects) might be to automatically move the mouse pointer into the window focused with alt-tab. I feel like that would at least make sloppy focus usable again.
Comment 10 Benjamin Melançon 2019-09-19 13:17:40 UTC
Just to be clear, this happens without any mouse/cursor movement at all, so it would not be expected to steal focus by sloppy focus' own terms.  It is a bug in Gnome's task switcher in Wayland.

And it's an annoyance it's still not fixed.  Ensuring my cursor is not in the latitude of the line of applications available to be switched between is the workaround.
Comment 11 Phillip Wood 2020-04-17 18:20:51 UTC
*** Bug 774697 has been marked as a duplicate of this bug. ***
Comment 12 Phillip Wood 2020-04-17 18:21:07 UTC
*** Bug 745380 has been marked as a duplicate of this bug. ***
Comment 13 Phillip Wood 2020-04-17 18:29:45 UTC
Created attachment 374260 [details]
Backtrace

This only seems to affect wayland, under X11 it works fine. Commit 612507260 ("Handle keynav vs. mousenav in mouse and sloppy focus modes. Fixes #167545.", 2005-02-22) [1] introduced code to track whether the window was selected by Alt-Tab to stop the focus switching back but that does not seem to have been fully implemented in the wayland version. I've attached a backtrace that shows the focus being switched by Alt-Tab (the first call to meta_window_focus()) and then switched back again by meta_window_handle_enter()

[1] https://gitlab.gnome.org/GNOME/mutter/-/commit/612507260a550ff2381bfcbbe32f9bab62650fd9
Comment 14 GNOME Infrastructure Team 2021-07-05 13:50:37 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/mutter/-/issues/

Thank you for your understanding and your help.