GNOME Bugzilla – Bug 726030
GtkMenu has unnecessary scroll handles
Last modified: 2018-05-02 15:59:39 UTC
I would like to describe a bug in GtkMenuItem (or GtkMenu or GtkMenuShell). The bug only surfaces in a very special edge case. Namely when the following THREE conditions are satisfied: * The menu is positioned at the bottom of the window AND * When this window is moved very close to the bottom of the screen AND * When menu items are added to this menu while the menu is opened Observed behavior: The result is that the menu will resize but its container. Since the new size will require more space but the menu is at the bottom of the window scroll handles are added to scroll through the menu. A screenshot can be seen at [3]. Expected behavior: The menu should reposition itself towards the top of the screen, this would allow the menu to resize without extending beyond the bottom of the window. A minimum working example can be found at my Github repository: https://github.com/lanoxx/gtk-menu-scroll-test The importent part happens in src/gtk-menu-scroll-test.c:menu_add_entry(), the function is called in a timeout interval of 2 seconds and keeps adding and removing two menu items to the first menu ("File") in the menubar. Move the window very close to the bottom of the screen and open it at a moment when the two menuitems are not attached to the menu. Then notice how the two items are added and the menu will get scroll handles. I have made the following additional observation: When I only add one menuitem instead of two then the menu resizes correctly but overlays the menubar because the menu extends towards the bottom of the screen. For me this indicates that the bug is located somewhere in the positioning code, possibly in [2]. More details about this bug can be found in [1]. Regards Sebastian [1] https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/965953 [2] https://git.gnome.org/browse/gtk+/tree/gtk/gtkmenuitem.c#n2081 [3] https://launchpadlibrarian.net/98501423/indicator-expander.png
(In reply to comment #0) > * When menu items are added to this menu while the menu is opened I think that's by design. The menu item that is currently under the mouse pointer should not change when items are added. More generally, I don't think applications should add menu items while a menu is open. What's your specific use case?
Hello Lars, I politely disagree: * This behavior is not observable when the menu is at the top of the window, since the menu will expand downwards and will have enough space to do so. * My use case is described in the attached launchpad bug [1] (see above). It most commonly happens in the various indicators (application, messaging, network, etc.). For example when I click on the network menu and then pull the network cabel or when I have the network manager menu open an I am waiting for a specific wireless network to be found. When I am looking for a wireless network I do not want to close and reopen the menu many times until I can see the network entry. I want it to appear as soon as the network is found. This is also the case when I place the menubar at the top of the screen, but it totally breaks when the menubar is at the bottom of the screen. * I also do not think this is by design, otherwise the bug would also be observable when menus are at the top of the window. It looks more like there is a bug in the positioning code. Kind Regards Sebastian
(In reply to comment #1) > (In reply to comment #0) > > * When menu items are added to this menu while the menu is opened > > I think that's by design. The menu item that is currently under the mouse > pointer should not change when items are added. It may be good idea to add option to allow to enable auto menu update when menu items changes. As Sebastian wrote - in network indicator I would expect menu to auto update rather then closing / re-opening menu many times. I will add example with dropbox... When I launch dropbox by default there is 5 menu items - Open Dropbox Folder, Connecting..., Prefereces..., Help Center, Quit Dropbox. If I open menu while it has not changed menu looks good - all items visible and there is no scroll buttons. Menu items is not updated while menu is open - I can leave with this and also this is not problem Sebastian wrote about. So now I close and reopen menu: 1) Menu items has changed - now there is 10 menu items. 2) Menu height has remained in old height - as it was with 5 menu items. 3) Scroll buttons has been added The problem is that opening menu next time it does not try to reposition menu and/or update height, but simply adds scroll buttons in cases when actually it is not needed.
I have looked into this a bit further, and now I think the bug is in gtk_menu_size_allocate. First thing I noticed is, if new menu items are inserted, then the height of the menu is not updated, that is `priv->requested_height` and height are not the same. The following trace shows this: http://pastebin.com/kLrfSuJF The height of the allocation and the requested_height are 171 and 177 respectively, but the local height variable only has a value of 135. After setting allocation->height equal to requested_height the menu extended properly but it still did not reposition correctly. I have added a call to gtk_menu_position() and removed the call to gtk_menu_scroll_to(). Removing gtk_menu_scroll_to() is of course not the final solution, but it gives an idea how this bug could be fixed. Could I have some input for this from a gtk+ dev?
Created attachment 272047 [details] [review] call gtk_menu_position in menu_size_allocate
This had no response in two month. So I am giving it a bump. Could a GTK+ developer please have a look?
Hi Sebastian, We tested your patch on top of GTK 3.10 in Linux Mint 17. Although it fixes the issues, we noticed it also caused a regression. I'll try to describe it the best I can using an example, so you can try and reproduce it. In Xfce, with the panel placed at the bottom we're using the indicator applet to show the sound-indicator and network-indicator. Prior to your patch, both of these would be ridiculously small in height and feature unnecessary scrollbars as soon as their content was changed (when an MPRIS app was launched for the sound indicator, or when wireless networks were scanned for the network indicator). After applying your patch, the left-click menu for both indicator worked as expected. However, right-clicking the indicator applet became problematic. The right-click content menu of the applet properly shows up... but it's "elusive".. i.e. it moves away from the mouse and is almost impossible to click :) It's worth noting that if the applet content doesn't change, that right-click context menu works as expected.
Hello Clement, I currently do not have enough time to create another patch. However there exists a second workaround which you also might want to try: http://bazaar.launchpad.net/~lanoxx/indicator-applet/menuitemfix/revision/430 With that fix the menu will appear correctly when it is opened the second time. I have not found a way to change this for opening the first time. I think the correct way to fix this would be in GTK+, but after several discussions on IRC and given Lars' comment, I have come to the conclusion that the GTK+ developers have no desire to fix this. Kind Regards Sebastian
Great. I'll try to see if we can close the regression in the GTK patch. If we can't, that indicator patch might come really handy. Thanks a lot for your work on this. Hopefully it will get in upstream GTK at some stage. It's helping us greatly already anyway. I'll get back to you here as soon as we know more.
Hello Clement, did you have any success with a patch for GTK+? Or did you settle with that indicator applet patch? Cheers Sebastian
Hi Sebastian, Sorry for not getting back to you. This issue went under the radar. It looked pretty serious to us at the time but it wasn't covered in the feedback we received from our community (i.e. it didn't seem to bother many users). As it is now it's still not fixed in our latest release. I'll add this to our Roadmap so we consider serving the indicator-applet patch through updates.
So what's the status of the bug today?
I don't think this will be fixed anytime soon, GTK developers do not seem to consider this bug important or even necessary to fix.
Hello. Could you step by step how to paint fix this problem. where to get the src / applet-main.c ? -------- return; } static void size_allocate (GtkWidget *widget, GtkAllocation *allocation) { int height = 0; if(GTK_IS_CONTAINER(widget)) { GList *children = gtk_container_get_children(GTK_CONTAINER(widget)); GList *l; for (l = children; l != NULL; l = l->next) { GtkAllocation ca; gtk_widget_get_allocation (l->data, &ca); height += ca.height; } } allocation->height = height; gtk_widget_set_allocation(widget, allocation); } static GtkWidget* create_menuitem (IndicatorObject * io, IndicatorObjectEntry * entry, GtkWidget * menubar) { g_signal_connect(G_OBJECT(menuitem), "enter-notify-event", G_CALLBACK(entry_secondary_activated), NULL); g_signal_connect(G_OBJECT(menuitem), "leave-notify-event", G_CALLBACK(entry_secondary_activated), NULL); g_signal_connect(G_OBJECT(menuitem), "scroll-event", G_CALLBACK(entry_scrolled), NULL); g_signal_connect(G_OBJECT(entry->menu), "size-allocate", G_CALLBACK(size_allocate), NULL); if (entry->image != NULL) { gtk_box_pack_start(GTK_BOX(box), GTK_WIDGET(entry->image), FALSE, FALSE, 1); ---------- and what to do with it?
Join us, hardir to the above. Please explain how to avoid this restriction. But basically very much like to solve this problem.
Created attachment 349600 [details] Unusable Network manager menu
This bug has been making Network manager on Xubuntu (and possibly other Linux variants) all but unusable for me, see e.g. https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/965953. I think there are a whole lot of people who will be very happy if this gets fixed. :)
I should add that in order for this bug to occur, it is not necessary that menu items are added WHILE the menu is open. If menu items are added via dbus WHILE the menu is NOT opened, then the menu's size will still be too small once the menu is opened. This behavior occurs because the window area of the menu popup is unable to grow towards the bottom, for example because there is already a panel or similar object placed immediately below the menu (e.g. when the menu opens upwards). In other words, moving the network manager applet to a panel located at the top of the screen fixes this issue in most cases. In this case, when recomputing the size of the menu, it should be considered, that the menu can grow towards the top of the screen, but apparently this is not done in the code.
-- 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/473.