724967 - All clicking action fails after sub menu open and close

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Alice0775 White]

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

Comment 1

[Karl Tomlinson (:karlt)]

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.

Comment 2

[Karl Tomlinson (:karlt)]

Attachment: 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.

Comment 3

[Karl Tomlinson (:karlt)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9c6893026006

Comment 4

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/9c6893026006