The default bug view has changed. See this FAQ.

"ASSERTION: How did that happen?" in nsGlobalWindow::ResetTimersForNonBackgroundWindow

VERIFIED FIXED in Firefox 7

Status

()

Core
DOM
P1
normal
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: Jesse Ruderman, Assigned: bz)

Tracking

(Blocks: 1 bug, {assertion, regression, testcase})

Trunk
mozilla8
x86_64
Mac OS X
assertion, regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox6 unaffected, firefox7 fixed)

Details

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
Created attachment 543760 [details]
testcase (requires popups to be enabled)

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

6 years ago
Created attachment 543761 [details]
stack trace
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
Created attachment 544645 [details] [diff] [review]
Don't try to unclamp the dummy timeout.
Attachment #544645 - Flags: review?(jst)

Updated

6 years ago
Attachment #544645 - Flags: review?(jst) → review+
Priority: -- → P1
Whiteboard: [need landing]
http://hg.mozilla.org/integration/mozilla-inbound/rev/9e84bca4fc42
Flags: in-testsuite?
Whiteboard: [need landing]
Target Milestone: --- → mozilla8
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?
status-firefox6: --- → unaffected
status-firefox7: --- → affected
http://hg.mozilla.org/mozilla-central/rev/9e84bca4fc42
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 years ago
Attachment #544645 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
http://hg.mozilla.org/releases/mozilla-aurora/rev/091434c8909e
status-firefox7: affected → fixed
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.
Yes, that's the intended behavior given the code in the testcase.
Thanks for the clarification.
Setting resolution to Verified Fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.