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: http://lxr.mozilla.org/seamonkey/source/layout/base/nsCSSFrameConstructor.cpp#8974 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): #!/usr/bin/perl $| = 1; print "Content-Type: text/xml\n"; print "\n"; print "<?xml version='1.0'?>\n"; sleep(5); print "<html xmlns='http://www.w3.org/1999/xhtml'>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.
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).
13 years ago
12 years ago
Flags: blocking1.9a1? → blocking1.9-
12 years ago
Depends on: 370812
bz, any chance this is related to the issue we ran into with document.open() 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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.