GNOME Bugzilla – Bug 86502
Active menu item not active after contex menu displayed for panel menu item
Last modified: 2020-11-06 20:24:42 UTC
I display Applications menu item of the panel and then Accesories and then move the mouse to Calculator. If I now right button click the context menu is displayed. When I press escape to dismiss the context menu item the Calculator menu item is no longer highlighted.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
I have been doing a lot of research on this problem, and I finally think I have an understanding of what the problem is. The problem as described in the original description is not exactly accurate, which became clear during my analysis. More specifically, the problem happens when the mouse cursor enters the pop-up context menu. In other words, if you use the keyboard to launch the pop-up menu, the "Calculator" menu item will stay highlighted (assuming the mouse isn't hovering where the pop-up appears). But when the mouse enters the pop-up menu, the "Calculator" menu item then becomes unselected. The deselect happens in gtk_menu_shell_leave_notify (gtkmenushell.c), which is called from gtk_menu_leave_notify (gtkmenu.c). When the pop-up is entered, the leave notify signal is sent for the "Calculator" menu item. In gtk_menu_shell_leave_notify, the gtk_menu_shell_deselect call is made, causing the "Calculator" menu item to deselect. Such deselects do not happen when moving the cursor between the normal menu hierarchy because the test for !GTK_IS_MENU_ITEM(event_widget) causes gtk_menu_leave_notify to just return TRUE before calling the parent class' (GtkMenuShell's) leave_notify_event function. It's not clear to me what the best way to address this problem. Should the panel's menu_shell's be set with ignore_leave? I suspect not, because the menu item should properly deselect if the cursor moves up the menu hierarchy (from "Calculator" to "Applications" for example) or if the cursor leaves the menu completely. Is there any way to inform the menuitem to ignore the leave signal if-and-only-if the cursor is moving into a context menu? I suppose that GtkImageMenuItem could be subclassed and have it's leave_notify method over-ridden to check for this case and ignore the event. Is this the most straight forward way to address this problem? One complication is that we probably only want the leave notify event to be ignored when going from the menu to the pop-up window. It is probably desirable for the deselect to happen when moving from the pop-up window back to the menu hierarchy. I would appreciate some guidance from someone who knows a bit more about GTK to suggest how this problem should be addressed. Thanks!
Is this bug a duplicate of bug #116012?
* No, it's not a duplicate * The ignore_leave flag has been removed in gtk-2-2 and HEAD - it wasn't doing anything useful. * Context menus on menus are fundementally bizarre from the GTK+ perspective; it's always been amazing that they work as well as they do. I wouldn't be suprised if you can't really get this to work properly without adding knowledge of the context menus to the GTK+ menu code; any time one bit of code stills a pointer grab away from another bit of code, it's likely to cause problems. (The restore_grabs() code in menu.c is a workaround for much more serious problems you would get ... which basically implies to me that this is a gnome-panel bug, not a GTK+ bug in any sense - it fundamentally doesn't work, the panel does hacks to make it work.) * Subclassing the menu item sounds unnecessary if you' are talking about extending the menu.c hacks - there is little you can do with subclassing you can't do with signal connections. What I'd suggest you do with this bug report is: - Move it back to the panel - File another bug against GTK+ asking for an API for context menus on menu items I don't really have a good idea how you can fix this problem within gnome-panel, but here's a guess - include gtkprivate.h (it is installed) and do: GTK_PRIVATE_UNSET_FLAG (menu_item, GTK_LEAVE_PENDING); Note that that has no guarantee of working, or even compiling with future 2.x versions of GTK+, but that's true of the current code in menu.c as well.
Though note with the suggestion above, it may well be that the menu item will stay highlighted even when it shouldn't stay highlighted; I'm not sure if that's better or worse.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
See http://mail.gnome.org/archives/desktop-devel-list/2005-March/msg00182.html for a possible way to fix this
Created attachment 46331 [details] Tarball with a possible way to fix this This is the tarball mentioned in the link above, so it doesn't get lost.
Just want to add some observations to this report: - open a menu and move to a menu entry, then open the context menu using the keyboard; if the pointer isn't anywhere near the panel or menu pressing escape gives focus back to the menu entry, and if the menu is anywhere on the panel, focus goes to the place it is hovering above. This means that if I click to open the Desktop menu, then use the keyboard to move into the menu and select an entry, pressing esc on the context menu gives focus back to the Desktop menu root which means the already open menu closes and a new one opens from where the pointer is placed. - for some reason I see my xchat icon on my top panel getting focus when I click on any of the menus in the toplevel panel. By that I mean it gets the dashed box drawn around it. This is the self added launcher that is leftmost on the panel. Looks kind of strange that a launcher icon is altered just by opening a menu.
Another thing. Sometimes I've been annoyed by menus just going away underneath my pointer when I wanted to activate an entry in them. Could it be that tooltips in the menus creates the same kind of situation where the focus on the menu entry is lost? I ask because the effect when clicking on the menu entry is the same, the menu entry is not activated and the menu just closes.
*** Bug 322437 has been marked as a duplicate of this bug. ***
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.