The default bug view has changed. See this FAQ.

CSS Frame Constructor does not construct root frame sometimes




12 years ago
5 years ago


(Reporter: Biesinger, Unassigned)


(Depends on: 1 bug)

Dependency tree / graph
Bug Flags:
wanted-next +
blocking1.9 -
wanted1.9 -

Firefox Tracking Flags

(Not tracked)



(1 attachment)

If there's no root content by the time PresShell::InitialReflow is called, then
CSSFC will never construct frames.

If InitialReflow did not construct the root frame, the if at:
8974       if (!mDocElementContainingBlock)
8975         return NS_OK; // [...]

is hit. ContentInserted then does nothing.

No other frames seem to be constructed either, I didn't trace exactly why, I
presume a null root frame prevented it.
Created attachment 189123 [details] [diff] [review]
start of a patch

this is a start of a patch, thanks to bz. (I have no plans in the near future
to finish it)

I found this bug while working on bug 1156; creating frames after DoContent but
before OnStartRequest/OnDataAvailable reliably triggers this, and that was the
case for <object data="some document type"> with that patch. workaround: create
frames before DoContent.
oops, the 1 || part of:
+        if (1 || !didReflow)
clearly needs to be removed for the patch to be useful.
So this can actually get hit if it takes some time for the root content to be
parsed and a frame reconstruct hits an nsSubDocumentFrame after Embed() got
called on its docshell but before the document has an mRootContent.  The only
thing that keeps this from being a problem for all <frame>/<iframe> tags is that
Embed() typically comes right before we parse the start tag for the root content.

The following CGI script triggers this bug (shows nothing when loaded in an
<iframe>, if the <iframe> gets a frame reconstruct while it's sleeping):

$| = 1;
print "Content-Type: text/xml\n";
print "\n";
print "<?xml version='1.0'?>\n";
print "<html xmlns=''>text</html>\n";

I'll post a testcase that shows that problem...

This sounds very much like bug 182460. It uses <script> tags in various places
to force us to do reflow in 'unexpected' places causing us to do initial layout
on an iframe containing an xml document before the xml document is fully loaded.

I did a bunch of more research in that bug but apparently I never commented on
all of it. The bug is filed on XSLT, but I can trigger it using just xhtml.
Though with just xhtml it just fails to render properly, it doesn't actually crash.
Blocks: 182460
So my conclusion of the way to fix this went something like this (working from
memory, so sorry about the lack of details).

The problem is that we when we lay out the <iframe>-frame (nsFrameFrame) start
layout on the contained document.

We can either fix this by checking if the contained document is a still-loading
xml-document. If so just don't start layout since the xmlsink will take care of
that for us.

Or we can entierly remove the need for the nsFrameFrame to start layout on its
contained document. It seemed like it was only needed for a few edgecases, which
might be better solved some other way.

Would either of these fixes solve the problem for bug 1156?
For bug 1156, the problem was solved by just reordering the order in which we
create the nsFrameFrame (actually nsSubDocumentFrame) and embed the content
viewer in the docshell.  So things are ok there.

In general, this might not be an XML-only problem; XML is just easier to work
with for testcases because its construction of the root content node is
predictable (unlike HTML, where <html> can just be made up by the parser).
Blocks: 309531
Flags: blocking1.9a1?
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [wanted-1.9]
Depends on: 370812
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+
bz, any chance this is related to the issue we ran into with and it needing to preserve the root node to not confuse layout? That was fixed (per our earlier conversation today), did that fix happen to fix this issue as well? Just asking cause johns ran into a reference to this bug in nsObjectLoadingContent.cpp.
Yes, the fix in bug 78070 should have fixed this issue too.
Depends on: 78070
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.