Last Comment Bug 669158 - "ASSERTION: How did that happen?" in nsGlobalWindow::ResetTimersForNonBackgroundWindow
: "ASSERTION: How did that happen?" in nsGlobalWindow::ResetTimersForNonBackgro...
: assertion, regression, testcase
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: x86_64 Mac OS X
: P1 normal (vote)
: mozilla8
Assigned To: Boris Zbarsky [:bz]
Depends on:
Blocks: 594645 647001
  Show dependency treegraph
Reported: 2011-07-04 06:39 PDT by Jesse Ruderman
Modified: 2011-08-23 00:35 PDT (History)
5 users (show)
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase (requires popups to be enabled) (493 bytes, text/html)
2011-07-04 06:39 PDT, Jesse Ruderman
no flags Details
stack trace (7.57 KB, text/plain)
2011-07-04 06:40 PDT, Jesse Ruderman
no flags Details
Don't try to unclamp the dummy timeout. (3.62 KB, patch)
2011-07-07 16:02 PDT, Boris Zbarsky [:bz]
jst: review+
asa: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Jesse Ruderman 2011-07-04 06:39:56 PDT
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.
Comment 1 Jesse Ruderman 2011-07-04 06:40:55 PDT
Created attachment 543761 [details]
stack trace
Comment 2 Boris Zbarsky [:bz] 2011-07-06 17:56:33 PDT

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.
Comment 3 Boris Zbarsky [:bz] 2011-07-07 16:02:33 PDT
Created attachment 544645 [details] [diff] [review]
Don't try to unclamp the dummy timeout.
Comment 5 Boris Zbarsky [:bz] 2011-07-08 14:11:24 PDT
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.
Comment 6 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-07-09 20:22:58 PDT
Comment 8 Trif Andrei-Alin[:AlinT] 2011-08-22 04:46:27 PDT
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?
Comment 9 Boris Zbarsky [:bz] 2011-08-22 11:49:54 PDT
Yes, that's the intended behavior given the code in the testcase.
Comment 10 Trif Andrei-Alin[:AlinT] 2011-08-23 00:35:20 PDT
Thanks for the clarification.
Setting resolution to Verified Fixed.

Note You need to log in before you can comment on or make changes to this bug.