GNOME Bugzilla – Bug 620863
Unable to select GtkMenu item above the current one with the cursor if the current one has a submenu
Last modified: 2010-06-08 19:59:07 UTC
Steps to reproduce this: 1. click on "Applications" 2. place your cursor over some item in the middle of the menu (so there is at least one item above it) with a submenu 3. wait for the submenu to open 4. move the cursor up to select the item above (in the applications menu, not the submenu) (all GtkMenus are affected, but I chose gnome-panel here, as this is the easiest to reproduce it with) Result: The old item remains selected while the cursor is hovering the item above Additional Information: You are able to select the item by clicking or by using the keyboard. Also selecting the item above the current one works again without clicking or using the keyboard. gtk version: 2.21.1-1ubuntu1 last working gtk version: 2.21.0-1ubuntu2 (both include the csd patches) I think it might be related to these patches: http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-22&id=43091232a2598c7d14834aec1e7b11806b1829c6 http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-22&id=239cfddc97fe3e42d9a0552b8d3c59b7bd0678b5
Created attachment 162953 [details] Demonstration of the problem
I suspect that those 2 patches might be related and the animation looks like something that definitely shouldn't happen, but I fail to reproduce the problem here. What the code is supposed to do is span a triangle from your mouse to the edge of the submenu and not select another menu item as long as the mouse is moving through that area. The idea is that when you move the mouse in direction of the submenu, you wanna select items in that submenu and not get confused by the submenu disappearing because you hovered over another item. After not reaching the submenu for a while or moving the mouse out of the triangle (like when moving striaght up as in your example), the code should stop to consume mouse events and resume normal operation. (It doesn't seem to do that either.) I suspect I got the math wrong somewhere, but as I have no idea how to trigger it - and I tried really hard for the last 5 minutes to convince gnome-panel to fail - I can't do a lot. One idea: It might be related to your theme - does it happen with Clearlooks for you? And if not: what theme are you running?
I tried changing the theme to Clearlooks, the font to Sans 10 at 96 dpi and it still happens here. These are the patches used by ubuntu, maybe it is related to one of these too: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/gtk+2.0/maverick/files/head:/debian/patches/?start_revid=166 The only patches that have changed between 2.21.0-1ubuntu2 and 2.21.1-1ubuntu1 are: 070_mandatory-relibtoolize.patch 072_indicator_menu_update.patch 091_bugzilla_tooltip_refresh.patch Or maybe the csd-patch somehow messes up the coordinates.
I can confirm this too: Fedora Rawhide with GTK+ 2.21.1 Seems that there is not a theme issue: the problem persist with the Raleigh engine.
Turns out it was important if the submenu was opened to the left or the right side. Should be fixed with this commit: commit af7f95207e2f45efd096f218167241653e9151a3 Author: Benjamin Otte <otte@redhat.com> Date: Tue Jun 8 21:45:15 2010 +0200 menu: Fix wrong comparison causing navigation region to not get removed The navigation region that got created for right-facing submenus when moving the cursor up would have two negative values which caused the check to go wrong. I refactored the code to make that check into a separate function as it makes the check not only harder to get wrong, but also the code easier to read. http://bugzilla.gnome.org/show_bug.cgi?id=620863