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 788844 - GtkMenu created from GMenuModel does not deactivate menu when activating a menu item with Space
GtkMenu created from GMenuModel does not deactivate menu when activating a me...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkMenu
3.22.x
Other All
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 745329
 
 
Reported: 2017-10-11 19:13 UTC by Christian Persch
Modified: 2018-05-02 19:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test case (2.67 KB, text/plain)
2018-03-16 10:56 UTC, Daniel Boles
Details

Description Christian Persch 2017-10-11 19:13:04 UTC
An item in a GtkMenu can be activated by several means, i.e. from mouse with a left click, or from keyboard by pressing Return, Enter, or Space.

When the menu is built the old-fashioned way, that is either manually by creating the menu with gtk_menu_new() and then creating the menu items with gtk_*_menu_item_new() and adding them to the menu with gtk_menu_shell_append(), or by creating the menu from GtkUIManager XML format, the activation of a (non-check) menu item causes the deactivation of the menu.

However, when you build the menu with gtk_menu_new_from_model(), the activation of the menu item with Space does NOT cause the deactivation of the menu.

At first, this seems only unexpected and surprising, but in my case this presents a real bug: When the activation of the menu (/ the GAction) causes a new window to be created (for example in gnome-terminal's File|Open Terminal item or its context menu's Open Terminal item), what happens is that the new window (shown with gtk_window_present[_with_time]()) opens *under* the still-open context menu, however the menu does not react to mouse movements anymore, and you have to dismiss it manually by clicking outside of it (it still reacts to the keyboard though).

AFAICT, the cause bug of this is that *check* menu items special-case activation by Space to 'toggle' the menu item, and behind the scenes, *all* menu items created by gtk_menu_new_with_model are check menu items.
Comment 1 Daniel Boles 2018-03-16 10:56:03 UTC
Created attachment 369773 [details]
test case

We don't have a test for gtk_menu_new_from_model() that I can see. So here's one.

You're right, of course, and nothing has changed. Clicking the Beep item here invokes the action but leaves the menu open.
Comment 2 Daniel Boles 2018-03-16 10:56:44 UTC
...er, not "Clicking", but pressing Space (not EnteR), of course
Comment 3 Daniel Boles 2018-03-16 11:20:58 UTC
(In reply to Christian Persch from comment #0)
> AFAICT, the cause bug of this is that *check* menu items special-case
> activation by Space to 'toggle' the menu item, and behind the scenes, *all*
> menu items created by gtk_menu_new_with_model are check menu items.

Enter calls ::activate-current with @force_hide = TRUE. Space calls it with @force_hide = FALSE, which leads to the decision of whether to hide being decided by GTK_MENU_ITEM_GET_CLASS(menu_item)->hide_on_activate;

GtkModelMenuItem is derived from GtkCheckMenuItem (which seems a bit unfortunate), whose hide_on_activate is FALSE. So, the menu doesn't get deactivated.

Can anyone see any nice way around this? A simplistic but possibly kludgey one would be to override the binding of Space in ModelMenuItem and force-close the menu if the current role is GTK_MENU_TRACKER_ITEN_ROLE_NORMAL (as the affected items have).
Comment 4 GNOME Infrastructure Team 2018-05-02 19:14:47 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/940.