Keyboard shortcuts (like Ctrl+Alt+T) or Multimedia keys (like Play/Pause) do not work if a right-click sub-menu (e.g. of the desktop, or an icon/file, or the panel) is active. Similarly, they do not work when opening the right-click menu in applications like gmusicbrowser, qpdfview, or Libreoffice (I'm not going to try every single one). They do not work either after opening a sub-menu in the panel by pressing any panel icon, or when a sub-menu is open in Thunar (e.g. Edit).
Why is this? Intuitively, it seems to be because an active sub-menu disables the ability of "the system" to "listen to a call from a shortcut". Is this correct?? Strictly speaking, is this not a limitation of the "listening ability" of the system?
Oddly (?), this does not happen when the right-click menu of Firefox is open.
Best Answer
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)
screen doesn't lock when some menu is open
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./