Closed Bug 443655 Opened 11 years ago Closed 2 years ago

"ASSERTION: A frame but no DOM element!?" removing two frames, one of which has an onunload that navigates the other

Categories

(Core :: Document Navigation, defect)

defect
Not set

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jruderman, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, crash, testcase)

Crash Data

Attachments

(3 files)

Attached file testcase
Loading the testcase (in Mac trunk debug Firefox) triggers:

###!!! ASSERTION: A frame but no DOM element!?: 'requestingElement', file /Users/jruderman/central/mozilla/docshell/base/nsDocShell.cpp, line 6678

This is the same assertion that fired in bug 369126.  I guess the fix in that bug missed this case.
OS: Mac OS X → All
Hardware: PC → All
(Bug 402982 added this code.)

Removing the iframe elements leads to nsFrameLoader::Destroy() which
calls 'doc->FinalizeFrameLoader(this)' on line 323:
http://hg.mozilla.org/mozilla-central/index.cgi/annotate/951ac1cf93a9/content/base/src/nsFrameLoader.cpp#l285
which in this case delays the Finalize() by appending it to
mFinalizableFrameLoaders on line 4425:
http://hg.mozilla.org/mozilla-central/index.cgi/annotate/951ac1cf93a9/content/base/src/nsDocument.cpp#l4415

In nsDocument::InitializeFinalizeFrameLoaders (stack frame #34) both frame
loaders are in the list, calling Finalize() on the first leads to
nsDocShell::Destroy() which runs FirePageHideNotification() which runs the
script that sets a new location for the second iframe which triggers the
assertion since 'mIsBeingDestroyed' is still false for the docshell
associated with the second iframe.

There is an interval from the time nsFrameLoader::Destroy()
disassociates itself from the docshell until nsDocShell::Destroy()
runs (in this case InitializeFinalizeFrameLoaders() but I think it
can also happen for the nsAsyncDocShellDestroyer() path) where this
assertion can trigger.

FWIW, making an early return if 'requestingElement' is null doesn't work
properly - it leaves the throbber spinning and clicking the Stop button
doesn't make it stop.  The only way I can make it stop is to run
FirePageHideNotification() earlier, from FinalizeFrameLoader(), but
I suspect this is not a solution since FirePageHideNotification()
is synchronous and probably unsafe to do at that point.
(In reply to comment #1)
> FWIW, making an early return if 'requestingElement' is null doesn't work
> properly - it leaves the throbber spinning and clicking the Stop button
> doesn't make it stop. 
The same happens if you remove the unload -part from the testcase.
So IMO that is a separate bug, but for this returning early could be ok.
Testcase still insta-crashes on trunk opt builds (and I assume would assert on debug builds).
Attached file stack for the crash
Interesting, I don't think this crashed when I first reported the bug.
Crash Signature: [@ nsCOMPtr<mozilla::dom::Element>::operator-> ] [@ nsDocShell::InternalLoad ]
Same symptoms as bug 854864.
Has Regression Range: --- → no
Flags: needinfo?(ryanvm)
This doesn't reproduce anymore.
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(ryanvm) → in-testsuite+
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.