Build Identifier: http://hg.mozilla.org/mozilla-central/rev/8f1b1574e4b0 Mozilla/5.0 (X11; Linux i686; rv:13.0a1) Gecko/20120207 Firefox/13.0a1 ID:20120207035004 In last m-c hourly. All clicking action fails after sub menu open and unexpectedly close. Reproducible: Always Steps to Reproduce: 2. Click menu in Menu bar 3. Mouse move[1] on a menu(like a folder) and Wait until the sub menu opens 4. Mouse move[1] to upper-ward/lower-ward -- all menu unexpectedly closed -- this is another bug. 5. Click x button in the Title bar Click menu item in the menubar Click any link in content note:[1]not drag Actual Results: Nothing happens. All clicking action fails. Expected Results: Should not fail Regression window(m-i) Works: http://hg.mozilla.org/integration/mozilla-inbound/rev/841b4395aa66 Mozilla/5.0 (X11; Linux i686; rv:13.0a1) Gecko/20120206 Firefox/13.0a1 ID:20120206175103 Fails: http://hg.mozilla.org/integration/mozilla-inbound/rev/050334f9128c Mozilla/5.0 (X11; Linux i686; rv:13.0a1) Gecko/20120206 Firefox/13.0a1 ID:20120206181401 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=841b4395aa66&tochange=050334f9128c In local build: last good ca19aff687a1 first bad 050334f9128c Triggered by: 050334f9128c Karl Tomlinson — b=500081 use a timestamp when grabbing the pointer and generate timestamps for drags in the same way r=roc

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.

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.