Closed
Bug 669158
Opened 13 years ago
Closed 13 years ago
"ASSERTION: How did that happen?" in nsGlobalWindow::ResetTimersForNonBackgroundWindow
Categories
(Core :: DOM: Core & HTML, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla8
Tracking | Status | |
---|---|---|
firefox6 | --- | unaffected |
firefox7 | --- | fixed |
People
(Reporter: jruderman, Assigned: bzbarsky)
References
Details
(Keywords: assertion, regression, testcase)
Attachments
(3 files)
493 bytes,
text/html
|
Details | |
7.57 KB,
text/plain
|
Details | |
3.62 KB,
patch
|
jst
:
review+
asa
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
The testcase triggers this assertion, usually within a few seconds: ###!!! ASSERTION: How did that happen?: '!IsTimeout(nextTimeout) || timeout->mWhen < nextTimeout->mWhen', file dom/base/nsGlobalWindow.cpp, line 9469 The function containing this assertion was added in bug 647001.
Reporter | ||
Comment 1•13 years ago
|
||
![]() |
Assignee | |
Comment 2•13 years ago
|
||
Taking. What's happening here is that the code in ResetTimersForNonBackgroundWindow assumes timers are stored in mWhen order, which is true _except_ in the middle of a timer firing. In that case, timers that come after it can have an earlier mWhen than the timer, apparently. That's the case we're hitting here, as far as I can tell: the b2 timer is firing, calls window.close(), that causes a switch back to the original window and an unclamping of some timer, etc. I'll dig into this a bit more to figure out exactly what's happening and how to fix it.
Assignee: nobody → bzbarsky
![]() |
Assignee | |
Comment 3•13 years ago
|
||
Attachment #544645 -
Flags: review?(jst)
Updated•13 years ago
|
Attachment #544645 -
Flags: review?(jst) → review+
![]() |
Assignee | |
Updated•13 years ago
|
Priority: -- → P1
Whiteboard: [need landing]
![]() |
Assignee | |
Comment 4•13 years ago
|
||
http://hg.mozilla.org/integration/mozilla-inbound/rev/9e84bca4fc42
Flags: in-testsuite?
Whiteboard: [need landing]
Target Milestone: --- → mozilla8
![]() |
Assignee | |
Comment 5•13 years ago
|
||
Comment on attachment 544645 [details] [diff] [review] Don't try to unclamp the dummy timeout. Requesting aurora approval for this. This should be a safe fix; all we're doing is not unclamping timers that we're about to fire anyway, so that the invariants we assume about the sorting of the timer list continue to hold.
Attachment #544645 -
Flags: approval-mozilla-aurora?
![]() |
Assignee | |
Updated•13 years ago
|
status-firefox6:
--- → unaffected
status-firefox7:
--- → affected
http://hg.mozilla.org/mozilla-central/rev/9e84bca4fc42
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Attachment #544645 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
![]() |
Assignee | |
Comment 7•13 years ago
|
||
http://hg.mozilla.org/releases/mozilla-aurora/rev/091434c8909e
Comment 8•13 years ago
|
||
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a2) Gecko/20110821 Firefox/8.0a2 I runned the testcase and the results are that when allowing popups, the tab switches to the popup tab,over and over again(i don't know for how long, i only runned it for a few minutes). Is that the intended behaviour? Thanks.
![]() |
Assignee | |
Comment 9•13 years ago
|
||
Yes, that's the intended behavior given the code in the testcase.
Comment 10•13 years ago
|
||
Thanks for the clarification. Setting resolution to Verified Fixed.
Status: RESOLVED → VERIFIED
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•