The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in mozilla8

Status

()

Core
Widget: Gtk
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: ttaubert, Assigned: ttaubert)

Tracking

Trunk
mozilla8
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Assignee)

Description

6 years ago
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.
(Assignee)

Comment 2

6 years ago
Created attachment 552947 [details]
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?
(Assignee)

Comment 3

6 years ago
Created attachment 552954 [details] [diff] [review]
patch v1

(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)
(Assignee)

Comment 4

6 years ago
Comment on attachment 552954 [details] [diff] [review]
patch v1

Passed try:

http://tbpl.mozilla.org/?tree=Try&pusher=tim.taubert@gmx.de&rev=30527793fbd0
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.
(Assignee)

Comment 7

6 years ago
http://hg.mozilla.org/integration/fx-team/rev/621138727ae4
Whiteboard: [fixed-in-fx-team]
http://hg.mozilla.org/mozilla-central/rev/621138727ae4
Target Milestone: --- → mozilla8
(Assignee)

Updated

6 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 6 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.