Closed
Bug 300540
Opened 20 years ago
Closed 13 years ago
CSS Frame Constructor does not construct root frame sometimes
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
People
(Reporter: Biesinger, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(1 file)
|
2.26 KB,
patch
|
Details | Diff | Splinter Review |
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.
|
Reporter | |
Comment 1•20 years ago
|
||
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.
|
|
Reporter | |
Comment 2•20 years ago
|
||
oops, the 1 || part of: + if (1 || !didReflow) clearly needs to be removed for the patch to be useful.
|
||
Comment 3•20 years ago
|
||
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?
|
|
||
Comment 6•20 years ago
|
||
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).
|
|
||
Updated•19 years ago
|
Flags: blocking1.9a1?
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [wanted-1.9]
|
||
Updated•17 years ago
|
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+
|
||
Comment 7•13 years ago
|
||
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.
|
|
||
Comment 8•13 years ago
|
||
Yes, the fix in bug 78070 should have fixed this issue too.
Depends on: 78070
|
|
||
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•