Thanks for the prompt bug reports. The patch in bug 724966 deals with the cause of the menus closing and so we don't see this bug with the given steps to reproduce. I'll still investigating why that lead to clicks failing, so please leave this report open.

Created attachment 595284[details][diff][review]
update mWidget before calling CaptureRollupEvents to handle rollup during the call
Now that bug 724966 is fixed, the pointer grab failure should be rare.
In can happen still however in the following situation, for example:
User clicks on menu, but a web page is busy and so the menu open is delayed.
The user moves on and opens a menu in another app. This prevents the Gecko
app from grabbing the pointer.
When the grab fails, it seems sensible to me to rollup rather than leave the
menu open when it may be above some other app and is in only a semi-working
state.
However, nsXULPopupManager::SetCaptureState is not written expecting rollup to
happen during CaptureRollupEvents(aDoCapture=true). During rollup
SetCaptureState is called again to call CaptureRollupEvents(false), but
mWidget is still null and so that is not called.
This code dates back to
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsMenuDismissalListener.cpp&rev=1.2#line_93
When CaptureRollupEvents(false) is not called, gtk_grab_remove does not get
called and so GTK redirects all events to the hidden window, which does not
receive them.
There are other possible fixes here. I prefer to avoid the complexity and
possible additional race conditions from doing Rollup off an event.
gtk_grab_remove could be called during check_for_rollup, or perhaps even when
the window is hidden. However, this change is simple and directly addresses
the problem.