I just ran into this issue on my laptop. I'm not certain why, since my install has been working fine for a few months, but just today all the shortcuts in the "Keyboard settings" ceased to work. As is hinted at briefly at the bottom of this thread, there seems to be a bad gnome configuration. I tried removing my ~/.gconf
folder (after making a backup first!) and logging out/in, and that fixed my problem. The full steps to fix were:
- Open up your home folder by pressing the Windows (or meta) key or by clicking on the first icon in the doc, then typing
Files
and opening the Files application.
- Show hidden files and folders by pressing Ctrl+H.
- Find the
.gconf
folder and rename it to .gconfg.bak
.
- Hide hidden files and folders again by pressing Ctrl+H.
- Log out of your account and back in. while some of your settings may be back to default, your shortcuts should work again.
This effect is due to a grab in X Windows. When I run a Wayland desktop in Fedora 25, even X apps inside XWayland no longer have this effect. A KDE bug relevant to this issue has been closed in favour of using Wayland.
Technically, whether a grab is used or not depends on the GUI toolkit / widgets used (or the application, if it talks to X directly). Many GUI toolkits use an X grab when a menu is open. However the reason for this - and how Firefox appears to avoid it - seems to be quite an obscure.
Another use of X grabs is for games, and nested desktops (e.g. remote access and virtual machines). When this answer was originally written, Wayland didn't support any method for getting the keyboard events they needed.[1][2]. Therefore it was unclear exactly how XWayland grabs would be treated, i.e. whether XWayland grabs will start having the specific effect you describe once again. Testing on Fedora 27 suggests not.
StackOverflow suggests that using an input grab, instead of setting the input focus to a child window, might be the only way to prevent window managers from redrawing the main window titlebar in the "inactive" color.
The most "official" sources I've been able to find about this are bug reports. It's clear the use of X grabs for menus has been a long-standing issue. If you read to the end, you'll see a suggestion which works around the window manager problem above. Perhaps this is what Firefox did.
(Thinking about it, I'm not sure that global keyboard shortcuts were as significant in the original desktop environments. I know Alt+Tab comes from CDE, but there's no obvious reason to use Alt+Tab while a menu is open).
Qt menu popups grab keyboard and pointer, preventing user from using system hotkeys (e.g. doing a screenshot)
The mechanism provided by X11 to implement popup menus is the global keyboard and mouse grab. All modern applications and toolkits use this mechansim, Qt included. Unfortunately, I don't see a way that this can be changed without some very serious behavioral changes (which will harm the user experience as well).
screen doesn't lock when some menu is open
this is answered by Michel in http://bugs.debian.org/514036
--8<-- Michel Dänzer
It does; it's the only way the menu can receive input events while the
pointer is outside of it. AFAIK this is a pretty deep X11 design issue,
so I'm afraid this can't be fixed easily. Feel free to bring it up
upstream though.
--8<--
OK. thx for this information.
I reported it to upstream:
http://bugs.freedesktop.org/show_bug.cgi?id=19946
I'm not clear that there is definitely a need for a keyboard grab to implement menus with access keys, even though that is what toolkits often do.
It may be convenient from the perspective that events are directed to the menu window.
But in most cases the main application window would have focus and so the application can receive keyboard events there.
If for some reason a client does not normally receive focus in the main window, I wonder whether it should negotiate keyboard focus (perhaps under the Globally Active Input model) rather than stealing a keyboard grab, which cannot be overridden until the client releases.
A pointer grab might be useful to be able to "click out" of the menu, by clicking anywhere else on the screen, but without actually triggering the element you clicked on. However Wikipedia says it is possible to grab the pointer without grabbing the keyboard./
Best Answer
It is very possible that you have a Chrome extension hijacking those keys -- for example, Plex or Google Play.
To investigate, head over to chrome://extensions/, and check out the "Keyboard shortcuts" link at the bottom of the page -- investigate to see which keys may be prioritized by Chrome extensions, e.g.:
Here, it's clear to see that Plex has taken control of the Media Play/Pause, Media Next Track, Media Previous Track, and Media Stop buttons. Simply click the
X
next to each to un-set that shortcut entirely, or reset the scope toIn Chrome
if you'd still like those shortcuts to work while a Chrome window is activated. An alternative is to just turn off the extension itself.The following links helped with this answer: http://www.makeuseof.com/tag/stop-chrome-hijacking-media-keys-heres/, http://www.omgchrome.com/chrome-google-music-media-keys/