Using a build that includes the patch for bug 731974, 1. Create a new profile 2. Install https://www.squarefree.com/extensions/domFuzzLite3.xpi 3. Replace prefs.js with the following: user_pref("browser.sessionstore.resume_from_crash", false); user_pref("toolkit.startup.max_resumed_crashes", -1); user_pref("dom.min_background_timeout_value", 4); user_pref("nglayout.debug.disable_xul_cache", true); 4. Run with the testcase on the command line Result: Crash [@ nsRefreshDriver::Tick], usually on the second time the testcase opens a new tab. At least on my laptop running Mac OS X 10.7, and a debug build from Tinderbox that was built from http://hg.mozilla.org/mozilla-central/rev/d9e032542831. It seems to be horribly dependent on timing. This might hold clues to topcrash bug 798872.

So what's happening here is that we're poking all our drivers in the timer, and when one of them runs, it causes a later one to be removed: 0[acd5f0]: [fc54401] ticking drivers... 0[acd5f0]: >> TickDriver: 3ebdeb8 (jsnow: 1349798419095175) 0[acd5f0]: >> TickDriver: 82e78c8 (jsnow: 1349798419095175) 0[acd5f0]: [7f570c8] RemoveRefreshDriver 82e7730 0[acd5f0]: >> TickDriver: 82e7730 (jsnow: 1349798419095175) but we try to poke it anyway since we took a copy of our list before we started. We hold refs to everything, so I can only guess that the Tick itself is doing something busted. I have an idea on how to fix it, though.

Simple fix -- just check if we were disconnected in Tick(). We have some helpers in DoTick/DoRefresh that are used for some internal test usages. I also added the assertions to the main Tick call as well. (This is on top of the patch in bug 731974; I'll fold them together when relanding, once I fix the winxp orange)

Comment on attachment 669628 [details] [diff] [review] don't Tick if we were disconnected I don't think you can assert !mFrozen. Another driver could have done history.back() on us and then spun the event loop until we are in fact frozen, no? So I suspect we need to just test for that just like we test for mPresContext. r=me with that

Landed as part of bug 731974 relanding. https://hg.mozilla.org/integration/mozilla-inbound/rev/5b727a94eebd

Hm, forgot to resolve this; this should have been fixed when 731974 finally landed. Is it still reproducible?

I haven't tested; just wanted to make sure it didn't get lost...

Seems ok with the testcase in comment 0, and with the other testcases I had lying around.

Tracking as fixed, QA please verify the testcase in FF20.

The Nightly debug builds from 2012-10-07 and 2012-10-08 seem to have some problems, they won't start on Mac. On Win, I couldn't reproduce the problem too. Anyway, I don't see any crash on FF 20 2013-01-22-mozilla-aurora-debug using the STR in comment 0.

I see 16 crashes on FF 20b1 in the last week: https://crash-stats.mozilla.com/report/list?signature=nsRefreshDriver%3A%3ATick%28__int64%2C+mozilla%3A%3ATimeStamp%29 Any thoughts?

More crashes appeared on 20 betas. Can anyone please take a look ? https://crash-stats.mozilla.com/report/list?signature=nsRefreshDriver%3A%3ATick%28__int64%2C+mozilla%3A%3ATimeStamp%29