GNOME Bugzilla – Bug 314298
pointer grab lockup
Last modified: 2005-08-29 18:39:57 UTC
Steps to reproduce (WARNING: you'll need to switch to console to kill gnome-panel afterwards): 0) Open panel menu, navigate to a submenu with applications 1) Right-click over an item 2) Press ESC twice to dismiss the context menu and the menu 3) Left-click somewhere on a blank space on the panel Actual results: The panel grabs the pointer, and never again releases it. The user cannot interact with any application with the mouse anymore! gnome-panel 2.11.92, gnome-menus 2.11.92
Doesn't happen on 2.10.x.
I can reproduce it with same version as above
This also happens for me (untz, please ignore what i said on IRC). version: 2.11.92 The pointer is changed in to drag mode after step 3. You can get the pointer back by pressing ALT+F1, the panel is still in a bad state since you only have to do step 3 to reproduce the bug. Panel works fine if you don't click on a blank space though.
The problem is with gnome-panel/menu.c: restore_grabs. It gets called when I dismiss the context menu on the menu items, but then also when I afterwards just click in the blank space on the panel.
Nominating as blocker for 2.12.0 because this is an extreme dataloss bug.
All pointer grabs (esp. if reproduceable) are showstoppers, so concurring.
*** Bug 312465 has been marked as a duplicate of this bug. ***
This is down to a behavioural change in gtk+. Basically, in a few places the panel relies on the fact that gtk+ would only emit a deactivate signal when a menu is active - in recent gtk+ you can get a deactivate signal at other times too. May need to fix this in the panel, but we'll see what the gtk+ guys say first. In more detail, here's what's happening: - The context menu on the panel's applications menu has some code to restore the grabs on its parent menu when its deactivated. However, the context menu isn't destroyed when its deactivated. At some later stage when any other grab is added (e.g. left-clicking on the panel or searching the treeview in Add to Panel) we get another "deactivate" signal and try and restore the grabs to the menu again - Similarily, the context menu on the panel itself pushes an "autohide disabler" when the menu is shown (this prevents the panel from autohiding while the menu is shown) and pops the disabler when the menu is deactivated. Again, the menu isn't destroyed and at some point later if we get notified of another grab we get another "deactivate" signal and assertions are spewed to stderr because we're trying to pop a non-existant disabler
Created attachment 51504 [details] test-menus.c Silly test case that shows the "second deactivate" behaviour which wasn't present in previous versions of gtk+ Just run it and hit Escape when the menu is shown
Created attachment 51505 [details] [review] gtk-menu-shell-hacky-dont-deactivate-when-not-active.patch Equally silly patch which makes the problem go away (purely illustrative)
This fixed it: 2005-08-29 Matthias Clasen <mclasen@redhat.com> * gtk/gtkmenu.c (gtk_menu_grab_notify): Only cancel if the menu was active. (#314298, Christian Persch, analysis by Mark McLoughlin)