Closed
Bug 678474
Opened 14 years ago
Closed 14 years ago
window.focus() doesn't work intermittently after multiple modal dialogs are opened quickly in succession
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
RESOLVED
FIXED
mozilla8
People
(Reporter: ttaubert, Assigned: ttaubert)
References
Details
Attachments
(2 files)
34.95 KB,
text/plain
|
Details | |
890 bytes,
patch
|
karlt
:
review+
|
Details | Diff | Splinter Review |
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
Comment 1•14 years ago
|
||
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•14 years ago
|
||
(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•14 years ago
|
||
(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 | ||
Comment 4•14 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 5•14 years ago
|
||
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+
Comment 6•14 years ago
|
||
(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•14 years ago
|
||
Whiteboard: [fixed-in-fx-team]
Comment 8•14 years ago
|
||
Target Milestone: --- → mozilla8
Assignee | ||
Updated•14 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 14 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.
Description
•