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.
Steps to Reproduce:
2. Click menu in Menu bar
3. Mouse move on a menu(like a folder) and Wait until the sub menu opens
4. Mouse move 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
All clicking action fails.
Should not fail
Mozilla/5.0 (X11; Linux i686; rv:13.0a1) Gecko/20120206 Firefox/13.0a1 ID:20120206175103
Mozilla/5.0 (X11; Linux i686; rv:13.0a1) Gecko/20120206 Firefox/13.0a1 ID:20120206181401
In local build:
last good ca19aff687a1
first bad 050334f9128c
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.
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
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
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
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