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 712228 - Hard-coded alt-tab behavior conflicts with configuration; breaks both.
Hard-coded alt-tab behavior conflicts with configuration; breaks both.
Status: RESOLVED DUPLICATE of bug 673078
Product: gnome-shell
Classification: Core
Component: general
3.8.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2013-11-13 15:57 UTC by Jeremy Nickurak
Modified: 2013-11-13 16:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jeremy Nickurak 2013-11-13 15:57:08 UTC
Hit this under Fedora 19, and Ubuntu. I've seen a number of other reports of the same thing from other users.

Steps to reproduce:
- In 'keyboard:shortcuts', configure alt-tab to be anything other than "Switch applications". For example "switch windows", or "switch to workspace 1"
- Press alt-tab

Expected behavior:
- "Switch windows" or "switch to workspace 1" behavior is triggered. 

Observed behavior:
- "Alt-tab" dialog opens, but doesn't let you switch more than one application away from whatever you're on.

100% reproducable here, on fedora 10, gnome-shell 3.8.4.

Note that if the "Switch applications" binding is cleared, alt-tab still opens the "switch-applications" dialog, and that everything still works fine if "Switch Applications" is bound to "alt-tab".

It seems like there's something hard-coded about alt-tab here, that is conflicting with configuration for alt-tab. The most consistent and intuitive thing here would probably be to make sure that all the bindings that exist exist in the user-visible settings, and that all user-visible settings are honored.
Comment 1 Jeremy Nickurak 2013-11-13 15:57:50 UTC
s/fedora 10/fedora 19/.
Comment 2 Jeremy Nickurak 2013-11-13 16:02:09 UTC
With "switch applications" unbound, I get the following:

nickuj@nickuj:~$ gsettings list-recursively | grep -iE 'keybinding.*switch-(window|app)'
org.gnome.desktop.wm.keybindings switch-applications ['<Alt>Tab', '<Alt>Tab']
org.gnome.desktop.wm.keybindings switch-applications-backward @as []
org.gnome.desktop.wm.keybindings switch-windows ['']
org.gnome.desktop.wm.keybindings switch-windows-backward @as []

With "switch applications" bound to "alt-tab", I get:

nickuj@nickuj:~$ gsettings list-recursively | grep -iE 'keybinding.*switch-(window|app)'
org.gnome.desktop.wm.keybindings switch-applications ['<Alt>Tab', '<Alt>Tab']
org.gnome.desktop.wm.keybindings switch-applications-backward @as []
org.gnome.desktop.wm.keybindings switch-windows ['']
org.gnome.desktop.wm.keybindings switch-windows-backward @as []
Comment 3 Jeremy Nickurak 2013-11-13 16:08:47 UTC
Manually clearing that field and then binding alt-tab correctly to 'switch applications' returns sanity, and I can't further break it from the UI.

However:

nickuj@nickuj:~$ gsettings reset org.gnome.desktop.wm.keybindings switch-applications
nickuj@nickuj:~$ gsettings list-recursively | grep -iE 'keybinding.*switch-(window|app)'
org.gnome.desktop.wm.keybindings switch-applications ['<Super>Tab', '<Alt>Tab']
org.gnome.desktop.wm.keybindings switch-applications-backward @as []
org.gnome.desktop.wm.keybindings switch-windows ['<Super>Tab']
org.gnome.desktop.wm.keybindings switch-windows-backward @as []

Subsequently, clearing the binding from gnome-control center gets us back to:

nickuj@nickuj:~$ gsettings get org.gnome.desktop.wm.keybindings switch-applications
['', '<Alt>Tab']
Comment 4 Florian Müllner 2013-11-13 16:11:24 UTC
Yeah, this is a known issue with gnome-control-center not considering secondary bindings for conflict resolution.

Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 673078 ***