Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 300540 - CSS Frame Constructor does not construct root frame sometimes
: CSS Frame Constructor does not construct root frame sometimes
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
Depends on: 370812 78070
Blocks: 182460 309531
  Show dependency treegraph
Reported: 2005-07-12 17:08 PDT by Christian :Biesinger (don't email me, ping me on IRC)
Modified: 2012-05-07 18:30 PDT (History)
8 users (show)
roc: wanted‑next+
dbaron: blocking1.9-
roc: wanted1.9-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

start of a patch (2.26 KB, patch)
2005-07-12 17:11 PDT, Christian :Biesinger (don't email me, ping me on IRC)
no flags Details | Diff | Splinter Review

Description Christian :Biesinger (don't email me, ping me on IRC) 2005-07-12 17:08:03 PDT
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.
Comment 1 Christian :Biesinger (don't email me, ping me on IRC) 2005-07-12 17:11:57 PDT
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.
Comment 2 Christian :Biesinger (don't email me, ping me on IRC) 2005-07-12 17:12:55 PDT
oops, the 1 || part of:
+        if (1 || !didReflow)
clearly needs to be removed for the patch to be useful.
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2005-07-12 21:01:47 PDT
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...

Comment 4 Jonas Sicking (:sicking) No longer reading bugmail consistently 2005-07-13 08:59:48 PDT
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.
Comment 5 Jonas Sicking (:sicking) No longer reading bugmail consistently 2005-07-13 10:26:44 PDT
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?
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2005-07-13 10:36:50 PDT
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).
Comment 7 Johnny Stenback (:jst, 2012-05-07 17:04:25 PDT
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.
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2012-05-07 18:30:02 PDT
Yes, the fix in bug 78070 should have fixed this issue too.

Note You need to log in before you can comment on or make changes to this bug.