GNOME Bugzilla – Bug 346603
[PATCH] Context menus only work once
Last modified: 2006-07-20 22:01:15 UTC
Please describe the problem: After a context menu is dismissed, further attempts to use a menu (context or otherwise) results in the menu failing to appear. This occurs because no grab-broken event is sent after the context menu is dismissed. Steps to reproduce: 1. Run tests/testtext 2. Right-click on the text view--a context menu appears. 3. Dismiss the menu either by choosing a menu item or clicking outside the menu. 4. Right-click again on the text view--no menu appears. 5. Click on the "File" menu in the menu bar--no menu appears. Actual results: No menus appear after the first context menu dismissal. Expected results: Menus continue to appear. Does this happen every time? Yes. Other information: Patch (to be attached) sends grab-broken events when a grab interrupts a previous grab. The X11 backend also sends grab-broken when a window is hidden or destroyed, do we need that in quartz as well?
Created attachment 68375 [details] [review] Patch to gdkevents-quartz.c
Created attachment 68436 [details] [review] Patch that works with paned containers Woops, the earlier patch broke GtkPaned containers, by trying to send a grab-broken event when an implicit grab on the sizer turns into an explicit grab. New patch works with GtkPaned, and still allows context menus to work.
Thanks, this also appears to make menus in general work a bit better. (There are still problems where a submenu will grab focus and moving the mouse over the parent menu or menu bar doesn't "re-grab".) I've committed this, thanks again.
I've tried to make it send a grab broken event also when the app loses focus, since now we leave menus up when minimizing the window, or focusing another app. I didn't get the menus to pop down by doing this but I will look some more at what happens.
If you'd care to post your code, I'll see if I can help :-) Note that the X11 backend works in a way I didn't expect. I thought the click would cause a grab-broken event, and then the menu would pop down in response. But instead it seems that the click causes the menu to destroy itself, which then causes the grab-broken event. Hopefully we don't have to emulate this strange behavior. While we're on the topic, here's another problem with context menu pop-downs: 1. Run gtk-demo 2. Open the Button Boxes demo 3. Invoke a context menu in the main gtk-demo window by right-clicking in the content area of the "Info" tab (you may have to move the Button Boxes window out of the way). 4. Try to dismiss the context menu by clicking back to the Button Boxes window. If you click on a button, the menu pops down. But if you click on a label or background, it doesn't pop down. It looks like the event mask is being compared against the place where you click, and not the pointer grab window. In find_window_for_event(), we're testing 'if (_gdk_quartz_pointer_grab_window && !pointer_grab_owner_events)', so in this case where owner_events is true we don't do the special-case for pointer events. Something about that must be the problem, but I honestly don't understand owner_events very well so I'm not sure how to fix it.
Created attachment 69262 [details] [review] Attempt at getting onfocusing working This is what I experimented with. The events are fired off but doesn't seem to have any effect.
[ Sorry, I haven't read this in detail, just responding to a small part of comment #5 ] I think trying to fool around with the grab mechanism in random ways to try and make menus "work" is a mistake. Most systems *don't* have anything equivalent to X (and thus GDK) grabs. E.g, when you say: I thought the click would cause a grab-broken event, and then the menu would pop down in response. But instead it seems that the click causes the menu to destroy itself, which then causes the grab-broken event. Hopefully we don't have to emulate this strange behavior. The only thing that could possibly be considered strange there is if you consider "grabs" to be part of menus. Grabs are completely indepedent and unrelated to focus in X. I've long argued that GtkMenu for Win32 and apparently for OS X as well needs a second mode of operation where it *doesn't* grab and deactivates the menu when the application loses focus. (Compare GTK+/Motif/etc. menus on X to Win32 menus and you'll find that on X when click away from a menu the click is eaten and on Win32 when you click away, the click is processed by other different app.)
Just FYI, Mac OS X also eats clicks when you click away from a menu.
Richard, your patch works if the calls to generate_grab_broken_event() use NULL for the last parameter.