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 789783 - fix or document lifecycle of attached popup menus
fix or document lifecycle of attached popup menus
Product: gtk+
Classification: Platform
Component: Widget: GtkMenu
Other Linux
: Normal enhancement
: ---
Assigned To: gtk-bugs
Depends on:
Reported: 2017-11-01 18:03 UTC by Christian Persch
Modified: 2018-05-02 19:24 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Christian Persch 2017-11-01 18:03:53 UTC
Previously, the lifecycle of popup menus was that you created one with gtk_menu_new(), populated it, and showed it with gtk_menu_popup(); the menu would get destroyed automatically after it was deactivated.

However, since now menus should (or, for GMenu based ones, *must*) be attached to a widget with gtk_menu_attach_to_widget(), the widget it's attached to takes a strong ref to the menu, so the menu is only destroyed once either detached from the widget, or the widget is destroyed. 

Thus, when you create a new popup menu for each context event (which is usual if you're building them custom to the actual context), the old menus build up on the attach widget, and are all destroyed together only when that widget is finally destroyed.

While the latter part is documented in the docs for gtk_menu_attach_to_widget(), it should make it clearer that the menu will *only* be destroyed at that time, not automatically when deactivated, and also the docs for gtk_menu_popup() (and gtk_popup_popup_at_*()) should mention this, and also document a way to avoid this buildup.

The way to manually avoid this buildup is to detach the widget from the attach widget once the menu is deactivated. The complication here is that you *cannot* do this in the 'deactivate' signal handler (which would appear to be the obvious place) because then the action you clicked in the menu will not be actually activated. Instead, you must use the 'selection-done' signal to detach the menu.
(Alternatively, menus should do that automatically, ie. when they're attached to a widget, the menu unattach itself on selection-done. That might be considered an ABI change, however.)
Comment 1 Matthias Clasen 2017-11-02 12:23:20 UTC
What made you file this bug ? I'm not aware of any changes in this area - gtk_menu_attach_to_widget has been around forever...
Comment 2 Christian Persch 2017-11-02 17:09:33 UTC
(In reply to Matthias Clasen from comment #1)
> What made you file this bug ? 

I ported gnome-terminal from GtkUIManager to GMenu, and from a context menu signleton to creating a new one each time the context menu is required, and had this 'buildup problem'. So I had to find a way to fix this, and the right place to detach the menu. Since that cost me some time, I thought others porting to gmenu (and thus necessarily using attach_to_widget) might save that time by having this documented.
Comment 3 GNOME Infrastructure Team 2018-05-02 19:24:41 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: