GNOME Bugzilla – Bug 747153
[regression] alt-tab extension requires two presses to activate
Last modified: 2016-10-07 13:08:38 UTC
The extension from here: https://extensions.gnome.org/extension/15/alternatetab/ which is a *supported* GNOME extension, requires you to press alt-tab *twice* for it to work. This is because a single press select the already selected window, and as a result, alt-tab-ing to the same window does nothing. This behaviour is different from the stock alt-tab functionality, and the functionality that has been present since I guess Windows 3.1 (but maybe something else before) So I guess it is a bug, and not a design choice :) Easily reproducible on an up to date F21. Cheers, James
(In reply to James from comment #0) > Easily reproducible on an up to date F21. I'm unable to reproduce it on 3.16/F22. Can you please either verify that the issue was fixed, or provide more detailed instructions on how to reproduce it?
(In reply to Florian Müllner from comment #1) > (In reply to James from comment #0) > > Easily reproducible on an up to date F21. > > I'm unable to reproduce it on 3.16/F22. Can you please either verify that > the issue was fixed, or provide more detailed instructions on how to > reproduce it? I don't currently have access to a F22 machine. I will happily test when it is released.
To reproduce, simply install the named extension, and press "alt-tab" and release. The window will still be at the current one. Pressing alt-tab,tab switches one window. And alt-tab,tab switches back.
(In reply to James from comment #3) > To reproduce, simply install the named extension, and press "alt-tab" and > release. The window will still be at the current one. I doubt the extension is to blame (it just changes some default shortcuts, the switcher itself is implemented in gnome-shell itself). However as mentioned, I cannot reproduce this with either the extension or the plain switcher - alt-tab switches windows, alt-tab switches back.
Here seems to be a way to reproduce in F21: * Have extension installed * Reboot * Alt-tab does bad behaviour as mentioned above To fix: * Turn off alt-tab extension * Turn it back on Things are now as normal... So perhaps you can try this to see how to reproduce. HTH, James
I am experiencing this behaviour as well on GNOME Shell 3.16.3 on Arch Linux. I do not have any extension that modifies the Alt-Tab behaviour, but, from time to time, I need to restart the shell in order to make Alt-Tab work properly (only one press to switch windows, instead of two). I have not find a way of reproducing it myself, but it happens everyday after some usage.
On fedora 24 with the extension enabled alt+tab randomly takes two presses, i've no idea what triggers and it often only happens once before vanishing It's one press to trigger the ui and it ignores further tab presses until the ui appears
It's been happening since fedora 22 and its random self-resetting nature is horribly maddening, was only when it got stuck in this state earlier today that i was able to confirm it was the shell and not me going crazy
Confirmed in Ubuntu 16.14, GNOME Shell 3.18.3. This bug is not sporadic for me. Could it be a weird setting interaction left from an upgrade <whatever GNOME Shell version was in Ubuntu 14.04> to 3.18.3? Is there some debugging we could turn on to provide more information?
I have found what causes the behavior for me: Steps to reproduce: 1. Enable extension AlternateTab 2. In the extension settings, check the box "Show only windows in the current workspace" 3. Use the Alt-Tab keyboard shortcut. (Window does not switch) 4. Use Alt-Tab-Tab. (Window switches to previous.) Steps to work around: 1. In the extension settings, clear the checkbox "Show only windows in the current workspace". 2. Use Alt-Tab. (Window switches to previous.) That should get really close to identifying the offending lines of code.
OK, so I think I found the reproducer - neither the extension nor the setting has anything to do with it, the problem is triggered by attached modal dialogs. Patch coming.
Created attachment 337116 [details] [review] altTab: Consider attached modals for window order Similar to bug 667552 for the app switcher, attached modal dialogs can result in an unexpected window order in the window switcher: Selecting a window with an attached dialog will focus the dialog instead, but as the dialog itself is ignored in the window list, its last-used timestamp is not taken into account for the position in the MRU list. Fix this by fetching the list of all NORMAL windows and filter out skip-taskbar windows ourselves, while making sure that windows appear in the position of their attached modal dialog where appropriate.
Review of attachment 337116 [details] [review]: looks fine
Attachment 337116 [details] pushed as d4ce51b - altTab: Consider attached modals for window order