GNOME Bugzilla – Bug 645026
Provide a global MRU list for alt-Tab as in gnome-shell
Last modified: 2021-07-05 13:48:18 UTC
Using 0c99f66547bedbac6c4ee8a6173e8699676bd44f, a bit after 2.91.91. Steps to reproduce: - Open emacs and something else in one desktop. I can only reproduce this with emacs (?). Make sure emacs is the active app in that desktop. - Go to the next desktop. - Come back. - Press Alt+Tab. Alt+tab will switch to emacs, even though you were already on it. In theory it should switch you to the other application.
Can you still reproduce this? I've got 3 workspaces; a bunch of stuff on #1, emacs and xchat on #2, and #3 is empty. (well, I tried with it empty and with it having a gnome-terminal). Alt+Tab always seems to DTRT for me. What do you see before typing Alt+Tab (is Emacs focused?) and what do you see in the Alt+Tab window?
(In reply to comment #1) > Can you still reproduce this? > Yep, still see it with master. > > What do you see before typing Alt+Tab (is Emacs focused?) and what do you see > in the Alt+Tab window? Emacs is focused. When I press Alt+Tab I get the overlay thing with the Emacs option highlighted. I'm using and old emacs from Fedora 13, so perhaps this is some bug in the app that has been fixed already.
(In reply to comment #2) > > What do you see before typing Alt+Tab (is Emacs focused?) and what do you see > > in the Alt+Tab window? > > Emacs is focused. When I press Alt+Tab I get the overlay thing with the Emacs > option highlighted. Is Emacs the first item in the list, or the second, and if it's second, what's first? Do you have multiple emacs windows, and if so, is the Alt-Tab dialog opening with the window thumbnails already visible? > I'm using and old emacs from Fedora 13, so perhaps this is some bug in the app > that has been fixed already. Apps don't really have much control over how Alt+Tab behaves, so probably not.
actually, are you (a) running gnome-shell on top of F13, (b) running F14/F15 with an old emacs package, (c) running F14/F15 with an emacs being remoted from an F13 box? If (c) that might be relevant
(In reply to comment #3) > Is Emacs the first item in the list, or the second, and if it's second, what's > first? Do you have multiple emacs windows, and if so, is the Alt-Tab dialog > opening with the window thumbnails already visible? Emacs is the second in the list, the first one is the gnome terminal. I only have one emacs window (and only one terminal window in that desktop).
(In reply to comment #4) > actually, are you (a) running gnome-shell on top of F13, (b) running F14/F15 > with an old emacs package, (c) running F14/F15 with an emacs being remoted from > an F13 box? > > If (c) that might be relevant I'm doing a) at the moment.
Installed Fedora 15 Beta, I can still see the bug.
Created attachment 187964 [details] [review] window: update user_time in meta_window_focus() We were updating user_time in meta_window_activate(), but not meta_window_focus(), which is what gets used by meta_workspace_activate(), so as a result, the ordering used by the shell Alt+Tab dialog would potentially be incorrect immediately after a workspace switch. ==== More specific how-to-reproduce: 1. put just a terminal window in workspace N 2. put just a terminal window and an emacs window in workspace N+1 3. focus the emacs window 4. Ctrl+Alt+Up (terminal gets focused) 5. Ctrl+Alt+Down (emacs gets focused) 6. type Alt+Tab; the order will be wrong, with terminal listed before emacs The trick is that gnome-terminal updates its user_time at step 4 (when you release Ctrl+Alt?), but emacs doesn't update its user_time at step 5. (In fact, it very rarely updates its user_time...). So as a result, gnome-terminal is more-recently-used than emacs at step 6. (The fact that we're using the user_time of a window on another workspace to decide what to select on this workspace is an unrelated and already-filed bug.)
Review of attachment 187964 [details] [review]: The question I have reading this is whether this makes sense for what user_time was originally meant for - focus stealing prevention - if a window becomes focused because I switching to (or past) a desktop, or closing another window that lies on top of it or whatever, does it now have a new user time, that should cause other windows to pop up underneath? (E.g., I start an application in the overview, leave the overview, switch desktops, end up on the workspace where the app starts, then the app starts, should the app be focus-stealing-prevented and get an "X is ready"?) Or, is this just a hack because of the use of the user time for a "global" mru list in GNOME Shell? Would it be better to add a global MRU list we maintain in parallel with the per-workspace MRU lists? I find it fundamentally confusing that we'd hack up the user time to get the MRU alt-Tab order right for GNOME Shell, with no connection between that and all the code in Mutter for maintaining the per-workspace MRU lists. If MRU == user time, that should be a consistent principle in the code. Also, if we do this, should the setting of user_time in window_activate() be removed?
*** Bug 654401 has been marked as a duplicate of this bug. ***
I think attachment 187964 [details] [review] fixes what I described in bug 654401, tested on top of mutter 3.0.2.1
(In reply to comment #9) > Or, is this just a hack because of the use of the user time for a "global" mru > list in GNOME Shell? Would it be better to add a global MRU list we maintain in > parallel with the per-workspace MRU lists? I find it fundamentally confusing > that we'd hack up the user time to get the MRU alt-Tab order right for GNOME > Shell, with no connection between that and all the code in Mutter for > maintaining the per-workspace MRU lists. If MRU == user time, that should be a > consistent principle in the code. Oh, this is related to another outstanding bug - see: https://bugzilla.gnome.org/show_bug.cgi?id=620744#c14 my proposed solution there is to revert out the per-workspace-mru lists and go back to a global mru list. And then do something else to fix bug 97635. If we had a global MRU list, then it would seem that we *really* want to expose that to GNOME Shell and let GNOME Shell interpret it in terms of applications rather than using the user time. I think I'm going to go ahead and try doing that today (bug 620744 has been sitting around annoying people far too long.)
this shouldn't still be NEEDINFO
(In reply to comment #9) > Review of attachment 187964 [details] [review]: > > The question I have reading this is whether this makes sense for what user_time > was originally meant for - focus stealing prevention - if a window becomes > focused because I switching to (or past) a desktop, or closing another window > that lies on top of it or whatever, does it now have a new user time, that > should cause other windows to pop up underneath? Some thoughts on this: * Focus stealing prevention has a couple of purpose: - Avoid having the user accidentally lose track of focus and type sensitive information somewhere it isn't supposed to go. (Though this is prototypical, but I think somewhat exaggerated - how much are you honestly going to type without seeing any feedback for your keystrokes? I think most of the time when someone types 'ls' into IRC it's a thinko rather than anything else.) - Avoid annoying the user if after doing something that would launch a new window, they go back and start doing something else, and the window pops over what they are doing. - Avoid having windows that pop up from a background activity annoy the user or steal keystrokes * We can never get focus stealing prevention exactly right, at least without an eye tracker - the time we want to "focus stealing prevent" is after the user starts *paying attention* to something else. This may be before they focus any other window, or do anything with the mouse or keyboard. * There's a fairly strong penalty for false-positives for focus stealing prevention. There's no nice way to say "hey, you tried to start this app, but now we're not going to show it to you until you click somewhere else" * So, basically, I think it would be fine if we said: - Focusing windows is never user interaction for focus stealing prevention And I think it would also be fine if we said: - Focusing windows *is* user interaction for focus stealing prevention it's just minor behavior differences that signify little. And it would also be fine if some sorts of focusing (alt-Tab'ing to a window, clicking on it) were user interaction some weren't, as is currently the case. But it would be nice if we were consistent between all applications about whether focus is interaction Wait, we are? ============== * The reason this bug doesn't happen with GTK+ applications is that GTK+ considers the Alt of Alt-arrows to be user interaction. If you make the following change to GTK+: diff --git a/gdk/x11/gdkdevicemanager-xi2.c b/gdk/x11/gdkdevicemanager-xi2.c index 29d8fa1..1a1d89d 100644 --- a/gdk/x11/gdkdevicemanager-xi2.c +++ b/gdk/x11/gdkdevicemanager-xi2.c @@ -1091,7 +1091,7 @@ gdk_x11_device_manager_xi2_translate_event (GdkEventTranslator *translator, _gdk_x11_event_translate_keyboard_string (&event->key); - if (ev->evtype == XI_KeyPress) + if (ev->evtype == XI_KeyPress && !event->key.is_modifier) set_user_time (event); /* FIXME: emulate autorepeat on key you can reproduce this with GTK+ applications. And should also be able to reproduce it as a race if GTK+ doesn't respond to alt before you hit Tab. A minimal change? ================= The above points out that this really has nothing to do with focusing, it's that certain apps make themselves "interacted" when you start alt-tabbing by hitting the alt key. So, one very confined possiblity would be simply to make the alt-Tab code in GNOME Shell force the currently focused app to the start of the alt-Tab list? But I guess to make that really reliable you have to memorialize that by setting the user time, you can't just do it temporarily. [ Forced to take off for the night before I can make this comment any longer and more confusing ]
(In reply to comment #14) > So, one very confined possiblity would be simply to make > the alt-Tab code in GNOME Shell force the currently focused app to the start of > the alt-Tab list? well... but having the alt+tab order not correspond exactly to MRU order is definitely wrong, and I'm not convinced that "sort by user_time and then promote the currently focused app" will get you exactly the MRU order in all cases. So it seems like it would be better to just export the MRU list and make Alt+Tab use that. And ideally that would be the global MRU list, I guess, since we need to correctly order the apps on the wrong side of the apps-on-other-workspaces bar. Or maybe we want to revisit the behavior of Alt+Tab with apps on other workspaces anyway.
Sorting by user time certainly doesn't give you the MRU order. The obvious case of this is sloppy focus, where an unfocused app can be receiving mouse events and updating its user time. I agree that it's weird and problematical to be maintaining a MRU list inside The issue with having only a global MRU list is sticky windows - if you have sticky windows, and go to an otherwise empty workspace, the sticky window gets focused and gets pulled to the top of the MRU list. Which is pretty broken. (The focused window when you go to a desktop needs to be the most recently used window on that desktop - you can't use stacking order as a proxy - in particular because of Always on Top windows) Various solutions to this: - Don't add windows to the MRU list in some circumstances - make simply switching to a workspace with a window focused not put in the MRU list (but then you have to make alt-Tab'ing away from the window add it to the MRU list so you get the expected toggle behavior) - Have a global MRU list *and* a per-workspace MRU list - Don't actually have a global MRU list, but have a last-added-to-a-workspace-mru-list timestamp that allows reconstructing it The second/third solutions are definitely way easier since we don't have to change any of the code in Mutter that references the MRU list, we just have to change the places that update the workspace mru list to update the global MRU list in parallel. (Step 1, add some encapsulation so code in core.c, window.c, isn't directly fiddling workspace->mru_list!)
*** Bug 643302 has been marked as a duplicate of this bug. ***
Created attachment 192003 [details] [review] altTab: fix app ordering in certain edge cases Because we were sorting the Alt+Tab list by user_time rather than stacking order / MRU, it was possible for the currently-focused window to sometimes not be the first app in the list. Fix this by using meta_display_get_tab_list() to get the proper MRU ordering of windows on the current workspace, and then convert that to an ordered list of apps. ===== OK, here's an alternate gnome-shell-only fix. If we later (re-)added a global MRU list, then we could change this to use that, to properly MRU the apps on other workspaces as well.
poke
Created attachment 199229 [details] [review] altTab: fix app ordering in certain edge cases Rebased to current HEAD
Review of attachment 199229 [details] [review]: Looks right to me and seems to work right with emacs (rebase was pretty trivial, but possible that I screwed something up)
Comment on attachment 199229 [details] [review] altTab: fix app ordering in certain edge cases Attachment 199229 [details] pushed as 928fbee - altTab: fix app ordering in certain edge cases
I can confirm that this bug continues to affect GNOME Shell on the version that's current with Fedora 17.
Is this still an issue in 3.26?
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.