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 738801 - Menus steal keybindings
Menus steal keybindings
Status: RESOLVED DUPLICATE of bug 100903
Product: gtk+
Classification: Platform
Component: .General
3.14.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2014-10-19 11:37 UTC by Tobias Getzner
Modified: 2014-10-20 06:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tobias Getzner 2014-10-19 11:37:33 UTC
As of GTK 3.14, when a menu has been opened (either via a button or via the menu bar), all keyboard events seem to be eaten up by GTK, even when they’re not bound within the application.

I have Hyper+$key and Super+$key bound within my shell. When I have a GTK 3.14 menu open, though, these events don’t trigger anymore until the menu has been closed manually.
Comment 1 Tobias Getzner 2014-10-19 17:45:25 UTC
Some other widgets also seem to do this. E. g., the text box in Nautilus’ file search. Though I’ve not yet observed the text box issue across other applications (the menu bug appeared in all GTK applications thus far).
Comment 2 Emmanuele Bassi (:ebassi) 2014-10-19 18:14:54 UTC
very likely, fall out from the gesture support landing — the grab that menus already hold is a bit too eager.

adding Carlos to the CC.
Comment 3 Matthias Clasen 2014-10-19 18:40:37 UTC
This has always been the case - menus grab the keyboard. I don't think anything changed here with gestures.
Comment 4 Emmanuele Bassi (:ebassi) 2014-10-19 18:55:29 UTC
mmh, I tried with Firefox and I could call `Super + H` to minimize it, even with a menu open, but Firefox is special in using GTK+ 2.x. I tried with a GTK+ 2.x app, and indeed I couldn't get `Super + H` through, so yep: no regression.

@Tobias: that's how GTK+ menus work with regards to key input, and there's nothing we can do about it.

*** This bug has been marked as a duplicate of bug 100903 ***
Comment 5 Tobias Getzner 2014-10-20 06:13:43 UTC
In the duplicate, it lists a rationale which doensn’t quite make
sense, though:
> GTK has to grab the pointer and the keyboard when it maps an
> override-redirect window like a menu or a combo box dropdown.
> Otherwise users could e.g. switch desktops using WM
> keybindings which is very annoying

Grabbing all input just for that seems a bit overkill.

For the menus this might be a minor (though disruptive) issue; how
about the text input in the Nautilus search box though? Is this a
widget issue or shall I file something against Nautilus? So far it
didn’t appear in other applications, but I don’t know whether
it’s a special widget or something.

Reopening for advice on the Nautilus issue.
Comment 6 Tobias Getzner 2014-10-20 06:21:19 UTC
I tried reproducing, and it seems I must’ve accidentally had
caps lock on when in the Nautilus search box, so that’s why
the bindings didn’t fire.

I’d still be interested in exactly why the menus have to grab
everything, though. The popover menus don’t do that either.

*** This bug has been marked as a duplicate of bug 100903 ***