Created attachment 323647 [details] partially reduced testcase Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a1pre) Gecko/2008053113 Minefield/3.1a1pre Steps to reproduce: 1. Load http://www.aetna.com/index.htm or the attached testcase. Result: ##!!! ASSERTION: Request list is not empty.: 'mRequests.entryCount == 0', file /Users/jruderman/central/netwerk/base/src/nsLoadGroup.cpp, line 354 ###!!! ASSERTION: Foreground URLs are active.: 'mForegroundCount == 0', file /Users/jruderman/central/netwerk/base/src/nsLoadGroup.cpp, line 355 ###!!! ASSERTION: Shouldn't be busy here: '!IsBusy()', file /Users/jruderman/central/uriloader/base/nsDocLoader.cpp, line 329 ###!!! ASSERTION: Overwriting an existing document channel!: '(loadFlags & nsIChannel::LOAD_REPLACE) || !(mDocumentRequest.get())', file /Users/jruderman/central/uriloader/base/nsDocLoader.cpp, line 514
Still happens on trunk.
Keywords: qawanted → testcase-wanted
I suspect this bug is also behind [orange] bug 471185. Please debug/fix before this partially reduced testcase stops working.
blocking2.0: --- → ?
bz, how bad does this sound to you? Doesn't seem like a regression, so I'm tempted to not block the release on this bug.
So what's going on here is that inside the subframe we get a location.href set. This calls Stop() on the subframe, which cancels all the channels in it. At that point the only thing blocking onload on the ancestor is the subframe, so onload fires synchronously and starts a new load in the subframe. We unwind to nsLoadGroup::Cancel and hit that first assert. Then we unwind to nsDocLoader::Stop and hit the second assert. And then we start the load from the href set, and hit that last assert. I don't think this is a regression. I'm not sure about how bad this is... I _think_ it should be nonfatal (might not have the right session history or throbber behavior, but shouldn't cause crashes and the like). When we switch to async onload firing (which we should), this should all get better.
Thanks bz, not blocking on this per bz's explanation above.
blocking2.0: ? → -
See also bug 675518, which has a testcase (but maybe an unrelated one).
The site in question has changed and the partially reduced testcase no longer asserts.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.