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.. 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
OK. thx for this information.
I reported it to upstream:
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./