GNOME Bugzilla – Bug 570641
Clicking on top panel doesn't dismiss "Actions" menu
Last modified: 2009-02-06 22:55:50 UTC
- Click on the user's name to drop down the actions menu - Click anywhere on the top panel - the actions menu doesn't deactivate and in fact you can trigger the overlay by clicking on the Activities menu The problem, I think is that A) GTK+ does a grab with OwnerEvents=True on the menu - since OwnerEvents is True, events to the same client (metacity) get delivered as normally. B) GTK+ does a gtk_grab_add() to get all the events going to that client, but it has no effect on our event handling which is bypassing GTK+. This probably could be fixed pretty easily for this menu where we control the activation, by for example, setting an empty shape on the input window temporarily while the window is up, but can we fix it more generically? Possible idea: use the ::grab-notify signal on a special toplevel that we create just for the purpose. I don't think you can use a GtkInvisible for this, but you might be able to use an unmapped toplevel. If it has to be mapped, it could be a GTK_WINDOW_POPUP positioned out of the visible area. (GTK + API enhancement to make this clean: be able to get the default window group and notification when the grab widget changes.)
I can verify that an unmapped toplevel gives me grab notifies. So the suggested solution is from that signal handler, we change the input-only X window in compositor core to pass through events somehow? I'm a bit unclear on what the "empty shape" suggestion refers to here. Is it using the X shape extension?
See the usage of: global.set_stage_input_area() In main.js. We're setting the "input shape" of the overlay window where the stage is drawn to catch events on some areas and not others. Currently we either grab input just on the top panel or on the whole screen. But if we (during a global GTK+ grab) took input nowhere, then the events would get delivered to the grab window.
Ahah, OK. Patch forthcoming.
Created attachment 128120 [details] [review] Bug 570641 - Use null input area when a GTK+ grab is operative This ensures that any popup windows we create in process, such as the user status menu, will get X events delivered even if the user clicks on the stage input area.
think you need to handle input area changes while grabbed.
Updated for IRC comments: <walters> owen: 1) aren't they handled now ? setting the area will reset the cache variables too, when we get ungrab we should ungrab to the right size 2) aren't we eating any X events that would cause us to change the input area? <owen> walters: 1) you should just change the variables while grabbed, and not also the input area 2) not sure about keybindings, but even if we were normally grabbing everything, timeouts, etc.It's better to just be robust here and not have to worry about it commit e2b246a0066a2511c2e2ab6691b22de7c1e227c9 Author: Colin Walters <walters@verbum.org> Date: Fri Feb 6 17:33:08 2009 -0500 Bug 570641 - Use null input area when a GTK+ grab is operative This ensures that any popup windows we create in process, such as the user status menu, will get X events delivered even if the user clicks on the stage input area.