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 726030 - GtkMenu has unnecessary scroll handles
GtkMenu has unnecessary scroll handles
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkMenu
3.8.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2014-03-10 11:59 UTC by Sebastian
Modified: 2018-05-02 15:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
call gtk_menu_position in menu_size_allocate (1.31 KB, patch)
2014-03-16 02:12 UTC, Sebastian
none Details | Review
Unusable Network manager menu (39.13 KB, image/png)
2017-04-10 12:43 UTC, smarnach
  Details

Description Sebastian 2014-03-10 11:59:54 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
Comment 1 Lars Karlitski 2014-03-10 16:49:18 UTC
(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?
Comment 2 Sebastian 2014-03-10 17:28:31 UTC
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
Comment 3 Alberts Muktupāvels 2014-03-11 07:53:18 UTC
(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.
Comment 4 Sebastian 2014-03-16 02:10:23 UTC
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?
Comment 5 Sebastian 2014-03-16 02:12:19 UTC
Created attachment 272047 [details] [review]
call gtk_menu_position in menu_size_allocate
Comment 6 Sebastian 2014-05-13 10:42:32 UTC
This had no response in two month. So I am giving it a bump. Could a GTK+ developer please have a look?
Comment 7 Clement Lefebvre 2014-06-12 11:36:15 UTC
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.
Comment 8 Sebastian 2014-06-12 12:10:42 UTC
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
Comment 9 Clement Lefebvre 2014-06-12 12:39:30 UTC
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.
Comment 10 Sebastian 2014-09-12 18:53:47 UTC
Hello Clement,

did you have any success with a patch for GTK+? Or did you settle with that indicator applet patch?

Cheers
Sebastian
Comment 11 Clement Lefebvre 2014-09-15 08:02:07 UTC
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.
Comment 12 Yan Pashkovsky 2015-07-11 10:13:01 UTC
So what's the status of the bug today?
Comment 13 Sebastian 2015-07-11 13:39:45 UTC
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.
Comment 14 hardir 2015-07-30 06:30:31 UTC
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?
Comment 15 Fedo 2015-07-30 12:40:58 UTC
Join us, hardir to the above. Please explain how to avoid this restriction. But basically very much like to solve this problem.
Comment 16 smarnach 2017-04-10 12:43:57 UTC
Created attachment 349600 [details]
Unusable Network manager menu
Comment 17 smarnach 2017-04-10 12:46:08 UTC
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. :)
Comment 18 Sebastian 2017-04-13 21:17:08 UTC
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.
Comment 19 GNOME Infrastructure Team 2018-05-02 15:59:39 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/473.