Closed Bug 724967 Opened 10 years ago Closed 10 years ago

All clicking action fails after sub menu open and close


(Core :: Widget: Gtk, defect)

13 Branch
Not set





(Reporter: alice0775, Assigned: karlt)



(Keywords: regression)


(1 file)

Build Identifier:
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)
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
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
OS: Windows 7 → Linux
Assignee: nobody → 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.
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
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.
Attachment #595284 - Flags: review?(enndeakin)
Attachment #595284 - Flags: review?(enndeakin) → review+
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.