GNOME Bugzilla – Bug 567671
extra long submenu popup delay
Last modified: 2018-02-10 03:39:13 UTC
Please describe the problem: Suppose you hover your mouse pointer over a GTK submenu entry long enough that GTK begins to activate the submenu popup. Then, as the popup submenu is loading, you move the mouse pointer over a different submenu entry (without clicking on it). Now, there is a longer than usual delay before the second submenu popup is shown. It seems like GTK is temporarily getting "stuck" loading the first submenu rather than responding to the new submenu it should be loading instead. I have been able to produce this problem in both the GNOME top panel menus and the menus in Gedit, so I believe it is a GTK+ bug. Steps to reproduce: 1. Add gtk-menu-popup-delay=0 in your .gtkrc-2.0 (this seems to make it easier to reproduce the bug). 2. Open gedit. 3. Expand the "View->Highlight Mode" submenu. This submenu contains more submenu entries ("Sources", "Scripts", "Others", "Markup", etc.) Move the mouse cursor up and down these menu entries without clicking. The bug usually happens when one submenu is in the middle of its popup process while I rapidly move my mouse pointer to another submenu entry and keep it there. Actual results: If it is still loading the first submenu popup by the time my cursor has reached the second menu entry, it will take a second or two before the system realizes that it has to expand the second menu entry since that is what my cursor is currently hovering on. During this time the visual menu entry selection indicator is positioned on the first submenu entry, not the second menu entry where my mouse pointer is at. Expected results: The expected behavior is for the system to immediately start loading whatever submenu the user's mouse pointer is currently hovering on, rather than imposing a delay if a submenu you have moused over is still in the process of being loaded. Does this happen every time? No. Other information: I originally reported this issue in the Ubuntu launchpad bugtracking system. There I was able to rule out the possibility that the problem was being caused by Compiz or my particular GTK theme. I was then told to send this bug upstream, so here I am :)
I've also noticed that setting "gtk-menu-popup-delay=7000" (or some other high delay) in ~/.gtkrc-2.0 causes the bug to become more obvious when it *does* occur. In this case, the proper submenu doesn't pop up until seven seconds after it should have.
Sorry, I meant "gtk-menu-popdown-delay=7000" in comment #1.
Okay, so I dug into this a little bit. Consider the scenario where one submenu is expanded and you move your cursor down to expand the next submenu. During normal operation, it seems like GTK first handles a "leave notify" event for the GtkMenu (which closes the existing submenu), and then it processes an "enter notify" event for the GtkMenuShell (which selects the new menu item that should expand into a submenu after gtk-menu-popup-delay msec). During abnormal operation (i.e. the bug happens), GTK first processes the "enter notify" event for the GtkMenuShell and then processes the "leave notify" event for the GtkMenu. I'm not sure what exactly is causing these events to be dispatched in reversed order. So I think it is either a bug in the event dispatcher or the assumptions that one of the two event handlers (gtk_menu_shell_enter_notify() or gtk_menu_leave_notify()) are making. I did notice that gtk_menu_leave_notify() schedules a callback that properly selects the new menu item after gtk-menu-popdown-delay msec. Thus, setting gtk-menu-popdown-delay=0 is a possible workaround. The GTK+ docs say that gtk-menu-popdown-delay specifies "The time before hiding a submenu when the pointer is moving towards the submenu." I don't quite understand this; is there ever a reason to delay the menu popdown with a config setting like this? At least in this particular case, it results in undesired UI behavior.
Without really reading the report in a lot of detail (sorry), are you sure that you aren't just seeing the normal and expected "triangle navigation"? If you move the mouse more or less straight down the menu, the submenus will pop down very quickly. If you move the mouse in the direction of a popped up submenu, then there is a longer delay. This longer delay is to keep you from having to "walk the plank" and move the mouse exactly through the item with a submenu to get to the submenu.
You're right, this feature does indeed appear to be what I keep accidentally activating. Would it be better to reduce the default popdown delay? Currently, DEFAULT_POPUP_DELAY=255 and DEFAULT_POPDOWN_DELAY=1000. This asymmetry makes it such that if you activate the popdown delay unintentionally, you get the extra long menu delay I observed. If we set both defaults to 225 (or at least make the difference smaller), then accidentally triggering the popdown delay in the wrong situation (which does happen to me periodically) will not be as noticable. I tested out triangular navigation using these settings too, and (for me at least) a popdown delay of 225 is enough. Has there been any particular reasoning / empirical support to motivate a default popdown delay as high as 1000?
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.