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 349037 - Hotkeys don't function when a menu or other popup/dropdown widget is active
Hotkeys don't function when a menu or other popup/dropdown widget is active
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: Other
unspecified
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2006-07-28 06:28 UTC by Porges
Modified: 2010-05-26 07:35 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description Porges 2006-07-28 06:28:45 UTC
Please describe the problem:
If a hotkey is set using gnome-keybinding-properties, when any of:
- an application menu
- a context menu
- another dropdown-like widget, such as comboboxes
is in use, the hotkey won't function.

Steps to reproduce:
1. Click on the main Gnome "Applications" menu.
2. Attempt to use a hotkey.

Actual results:
Nothing.

Expected results:
The hotkey to work as normal.

Does this happen every time?
Yes.

Other information:
Not sure if this is the place where this should really be filed (no idea about how the hotkey requests are routed internally), but it seemed like the best place to put it.
Comment 1 Matthias Clasen 2006-08-05 18:42:29 UTC
This can't work, due the way menus are implemented in X11.
Comment 2 Nicolò Chieffo 2007-06-05 09:29:00 UTC
Any better explanation please?
Comment 3 Matthias Clasen 2010-01-25 21:53:22 UTC
menus are implemented with keyboard and pointer grabs
Comment 4 Anders Kaseorg 2010-05-26 06:13:46 UTC
And if menus were not implemented with keyboard and pointer grabs, this problem would go away, right?

Would that have any other undesirable side effects?  It would mean that clicking outside of the menu on another application would actually send a click to the other application, but that actually sounds desirable (I _did_ click on it!).

It seems really arbitrary and broken that (say) a laptop’s volume controls stop working while a menu is open, and I think coming up with a way to fix this behavior is a valid request.

So, can this design decision perhaps be reexamined?

(This is, by the way, not the only bug related to menus grabbing the keyboard and pointer.  As another example, the NetworkManager applet menu grabs them and sometimes doesn’t let go for several seconds while it goes off to make dbus calls <https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/578074>.)
Comment 5 Emmanuele Bassi (:ebassi) 2010-05-26 07:35:54 UTC
see bug 100903 for the technical reasons of why menus cannot be implemented without keyboard and pointer grabs. commenting on a RESOLVED WONTFIX bug has no effects: either start a discussion on the mailing list on how to design a solution (across toolkits) or start a proof of concept patch that does not introduce regressions and open a bug.