GNOME Bugzilla – Bug 145416
Error dialogs and menus
Last modified: 2011-02-04 16:18:46 UTC
If you have the menus open when an error dialog appears, the error dialog appears /behind/ the menus. This is particularly fun because the menus don't let anything else on the X server receive events and the error dialog doesn't let anything except itself from receive events. Therefore, if the Ok button is obscured it looks like an X deadlock (although if you know that space will dismiss the dialog it's not as bad). One way to reproduce is to have totem have a bogus file in its initial playlist that it then tries to load on startup and open one of the menus when the window appears.
I could reproduce that problem, but it's not Totem related, it could happen with any GTK+ application. I attached a test case for it below, simply compile the .c file with: gcc -o foo foo.c `pkg-config --libs --cflags libglade-2.0` and run it in the current dir: ./foo Simply click on the menu, before the dialog pops up.
Created attachment 29350 [details] menu-on-top-of-dialog.tar.gz
The stacking is not fixable. The fact that the error dialog grabs the grab away from the menus may be fixable, though it's going to make the grab mess in GTK+ messier. Probably what you really want is to unpost any active menus when the dialog comes up, though that also is pretty tricky in the GTK+; maybe just special case and have gtk_dialog_map() call gtk_menu_deactive_all (screen) (screen? display? grab group?)
Should probably be looked at in connection with the tentative grab-broken signal
*** Bug 156773 has been marked as a duplicate of this bug. ***
*** Bug 143485 has been marked as a duplicate of this bug. ***
*** Bug 156009 has been marked as a duplicate of this bug. ***
Created attachment 48419 [details] [review] add grab-notify to GtkMenu Here is a proposal to handle this by canceling the menu if it gets grab-shadowed by something that is not a menu. This exception is necessary since submenus do grab-shadow their parents regularly. While it is theoretically possible that a menu gets grab-shadowed by an unrelated menu that is not a descendent in the menu hierarchy, this seems a pretty unlikely scenario, and b) since both menus are override-redirect, the shadowing one will end up above the shadowed one in the stacking order, so the deadlock described above will not occur. The patch seems to be a little less than perfect for torn off menus, where the selection is not removed in the torn-off menu when a submenu is grab-shadowed. I don#t know why that is, canceling the submenu with Escape has the right effect of removing the selection...
2005-06-27 Matthias Clasen <mclasen@redhat.com> * gtk/gtkmenu.c (gtk_menu_grab_notify): Cancel menus when they are grab-shadowed by something thats not a submenu. (#145416, Euan MacGregor)