Closed Bug 678474 Opened 8 years ago Closed 8 years ago

window.focus() doesn't work intermittently after multiple modal dialogs are opened quickly in succession

Categories

(Core :: Widget: Gtk, defect)

x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla8

People

(Reporter: ttaubert, Assigned: ttaubert)

References

Details

Attachments

(2 files)

I have a test that fails >80% of the time on my local machine. It sometimes fails on try, too. The problem is that waitForFocus() times out because (nsIFocusManager.activeWindow == null) _but_ (gtk_window_is_active() == true). So window.focus() does nothing and no focus event is dispatched.

My testcase is a page with an onbeforeunload, an onunload and an onpagehide handler that shows a confirm() or alert() dialog. So when closing that tab there are three modal dialogs that I close on after the other. The test finishes but the mochitest framework hangs while waiting for focus.

I tried to understand how all this works (with tons of debug output) and guess that the following happens:

1.) a modal dialog is shown
2.) the modal dialog gets closed
3.) gdk_window_show_unraised() gets called in nsWindow::SetFocus()
4.) we wait for the "focus_in_event" signal
5.) the next modal dialog shows up, calls self.showModal() and that calls EnableParent(false)
6.) the main browser windows is now (mEnabled == false)
7.) the "focus_in_event" signal for the main window arrives _but_ the browser window is not enabled, so no "activate" event is dispatched
8.) we're now in a state where GTK says the window is raised but we think otherwise
9.) window.focus() doesn't work anymore
Thanks for the analysis.  It sounds like we should not skip dispatch of the activate event when mEnabled is false.  That would be consistent with Enable(PR_FALSE) not doing anything to lose focus.

Are you able to confirm, please, that the the modal dialogs are not receiving focus before they are closed?

NSPR_LOG_MODULES=Widget:5,WidgetFocus:5 in the environment may be helpful.
Attached file log output
(In reply to Karl Tomlinson (:karlt) from comment #1)
> Are you able to confirm, please, that the the modal dialogs are not
> receiving focus before they are closed?
> 
> NSPR_LOG_MODULES=Widget:5,WidgetFocus:5 in the environment may be helpful.

I hope the attached log file helps you. It's the complete run of the hanging test.

This looks suspicious, just before the test hangs:

###!!! ASSERTION: Uh, IsInModalState() called w/o a reachable top window?: 'Error', file /home/tim/workspace/mozilla-central/dom/base/nsGlobalWindow.cpp, line 6728

Is that possibly the result of the described erroneous state?
Attached patch patch v1Splinter Review
(In reply to Karl Tomlinson (:karlt) from comment #1)
> Thanks for the analysis.  It sounds like we should not skip dispatch of the
> activate event when mEnabled is false.  That would be consistent with
> Enable(PR_FALSE) not doing anything to lose focus.

Is this what you had in mind?
Assignee: nobody → tim.taubert
Status: NEW → ASSIGNED
Attachment #552954 - Flags: feedback?(karlt)
Comment on attachment 552954 [details] [diff] [review]
patch v1

Thanks.  The mEnabled test here replaced a similar test in bug 567704.
Bug 567704 comment 14 explains why I think it is unnecessary.
Attachment #552954 - Flags: feedback?(karlt) → review+
(In reply to Tim Taubert [:ttaubert] from comment #3)
> This looks suspicious, just before the test hangs:
> 
> ###!!! ASSERTION: Uh, IsInModalState() called w/o a reachable top window?:
> 'Error', file
> /home/tim/workspace/mozilla-central/dom/base/nsGlobalWindow.cpp, line 6728
> 
> Is that possibly the result of the described erroneous state?

I don't know what that means, but it shows up after cause of the problem.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
You need to log in before you can comment on or make changes to this bug.