5

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.

5
+50

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./

  • Well, I don't think your post really explains why this is happening. Please elaborate. – luchonacho Apr 8 '17 at 10:15
  • That would be because I don't really know more, than it being an X grab. Here is a dump of google results anyway. It seems fairly academic, unless you are developing the specific GUI code that has to handle the X details. It's always been broken, there's some new workaround that maybe someone started using. The root problem hasn't been fixed for years. There's no way that's going to change, because we're switching to Wayland instead. Where XWayland doesn't have the problem. – sourcejedi Apr 8 '17 at 12:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.