Created attachment 145011 [details]
Full trace

Bugzilla ate my full trace. Uploaded as attachment. :(

It works for me now, Ubuntu 64-bit 9.10, 2.28.1~14-g988d-0~ricotz1

i've spent the last couple days looking into this, and all that i can figure out is that for some reason the workspaces submenu isn't receiving mouse events.  workspaces can be selected using the arrow keys, but the menu items don't even highlight when moused over.  the events are passed through the main event_callback() as per usual.  i've tried setting the event mask for the submenu and it's items with no change.  if anyone has a clue why this is happening, i'd be happy to write a patch

hmm, if it's working now, cancel that last post.  doesn't seem to be in the git tree however...

I'm still seeing this bug with git master as of today. It happens with any GtkMenu that is popped-up inside the Mutter process (either Mutter itself or a plugin).

It seems Mutter does some checks so it doesn't end up managing it's own window, the menu end's up being caught into this, and is marked as override-redirect and therefore some funkiness seems to happen with the mouse grabs (keyboard nav works fine).

I'm going to play around with this to see if can be solved by not including menus in the checks, but if someone with more experience with Mutter internals could give some guidance, that would be great.

That made less sense than I would like it to have :) Of course menu windows are override_redirect, however it does seem that something special is happening between what a GtkMenu would like to do and what Mutter wants to do. I'm going to play around with trying to diff the states between menus from mutter and those from external apps.

My random guess is we are getting the mouse event, but we need to be letting GDK handle it.

(Or even better, remove/reimplement the window menu in Clutter/St)

Based on the little bit of digging around I did back when I commented on this, IIRC mutter isn't even receiving the event, even though by all accounts it should.  I question though the need for the menu, or at least the current implementation.  As it is now, we have the choice to move to one of four workspaces, which was fine back in the days of gnome-session, but doesn't really make any sense now with gnome-shell given the variable number of workspaces.  Move to workspace left/right doesn't either, as the workspaces are arranged in two dimensions now instead of one.  If the menu is to stay, perhaps limit the options to Move to workspace Up/Down/Left/Right or something similar?

On the input side of things, enabling input debug in clutter shows that clutter is not seeing event inputs either.

Have been taking a deeper look into this, and comparing it to metacity too. It seems the issue only happens with Mutter, not with Metacity or Metacity-composited.

The xevent that Mutter receives has it's xevent->xany.window set to the initial GtkMenu that was popped-up, the submenu never receives mouse events "addressed" to it's window (whereas in Metacity the events clearly come with the correct xany.window attribute when the submenu is open).

Looking at the filter, both Mutter and Metacity are returning FALSE in event_callback and so the event is being sent to gdk it seems. There is no obvious fail of the grab, but I'm now inspecting that code path more thoroughly.

A little tricky to debug. I'll admit that I was stepping through event delivery code in the X server before the light dawned.

Basic problem, as you saw, is that events were going to the grab window (the parent window) rather than the submenu. This was the case even though gdk_pointer_grab() was being done with owner_events=TRUE.

You can see what is going on by carefully reading from the 

   If owner_events is True and if a generated pointer event would
   normally be reported to this client, it is reported as usual. 
   Otherwise, the event is reported with respect to the grab_window and is 
   reported only if selected by event_mask.  For either value of
   owner_events, unreported events are discarded.

Note that it is "normally be reported to this client" not "is on a window owned by this client".

So, if we aren't selecting for pointer events on the window where the pointer is in, it's just like it is a window from a different process - the event will be reported with respect to the grab window.

And indeed, Mutter was messing up the event mask on windows created by GDK in the same process. It didn't matter for the menu, because the window was the same as the grab window, but caused problems for the submenu where the window and the grab window were different.

Will attach a fix. The second hunk isn't actually necessary to fix this particular problem since the menu is created fresh every time, but is good to fix now before it causes someone to waste a lot of time debugging later.

Created attachment 165916 [details] [review]
Don't screw up the event mask when "managing" our own windows

When we do pseudo-management on an override-redirect window, we have to be
careful to augment the existing event mask, not replace it, or
delivery of pointer events will be disrupted.

When we unmanage a window, we shouldn't try to unselect events at all,
since that will interfere with event selection done by GDK.

http://bugzilla.gnome.org/show_bug.cgi?id=597763

Comment on attachment 165916 [details] [review]
Don't screw up the event mask when "managing" our own windows

looks good, and afaik, mutter won't freak out if it gets unexpected events for a window it doesn't care about any more

Works wonderfully

I confirm that this works with the latest git

Unless there is some outstanding issue with the patch, can we get this pushed and the bug closed?  It'd be nice to have this issue fixed in the git tree.

Thanks

Attachment 165916 [details] pushed as e590cd2 - Don't screw up the event mask when "managing" our own windows

*** Bug 630799 has been marked as a duplicate of this bug. ***