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

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect)

Description

[Jesse Ruderman]

Attachment: 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

Comment 1

[Jesse Ruderman]

Still happens on trunk.

Comment 2

[Jesse Ruderman]

I suspect this bug is also behind [orange] bug 471185.  Please debug/fix before this partially reduced testcase stops working.

Comment 3

[Johnny Stenback (:jst)]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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.

Comment 5

[Johnny Stenback (:jst)]

Thanks bz, not blocking on this per bz's explanation above.

Comment 6

[Jesse Ruderman]

See also bug 675518, which has a testcase (but maybe an unrelated one).

Comment 7

[Ryan VanderMeulen [:RyanVM]]

The site in question has changed and the partially reduced testcase no longer asserts.