If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

"ASSERTION: Request list is not empty" with iframe, https, redirect, reload (?)




Networking: HTTP
9 years ago
2 years ago


(Reporter: Jesse Ruderman, Unassigned)



Mac OS X

Firefox Tracking Flags

(blocking2.0 -)




(1 attachment)



9 years ago
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.


##!!! 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

Comment 1

8 years ago
Still happens on trunk.
Keywords: qawanted → testcase-wanted

Comment 2

8 years ago
I suspect this bug is also behind [orange] bug 471185.  Please debug/fix before this partially reduced testcase stops working.
Blocks: 471185
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: ? → -

Comment 6

6 years ago
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.
Last Resolved: 2 years ago
Keywords: testcase-wanted
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.