On this page there is a comment at the start : <!--@@Advance "Dreamspell"-> and right near the bottom there is another one : <!--@@Count "Dreamspell"->. WebKit ignores everything between these comments, whereas other browsers (Firefox, opera and IE Mac) display the page as the author 'intended'.
Created attachment 7991 [details] A reduction
The symptom gets fixed with reverting the SGML comment parsing fix made for acid2 (cf. bug 5855). However, there is another related problem - the test is parsed in strict mode, while it apparently shouldn't. Here, strict mode is triggered by having the <!--@@Advance "Dreamspell"-> comment anywhere before BODY.
Created attachment 8023 [details] proposed fix Properly determine the parsing mode if we have reached Frame::endIfNotLoading() without ever seeing any data from the decoder, which is the case when a broken comment is somewhere before <body>.
Comment on attachment 8023 [details] proposed fix Why does this new code belong here rather than in Frame::write? What's different about end as opposed to write that means we should do setParseMode in there, but determineParseMode here?
There are two Frame::write() methods, one also calls determineParseMode(), and another calls setParseMode(Strict). When loading data, it is the first that gets called, so we end up with calling determineParseMode() consistently. I didn't investigate why the second Frame::write() just sets strict mode, as it's not directly related to this issue. Looking at it now, it is used for documents created via document.write(), window.open(), DOMImplementation::createHTMLDocument(), Frame::replaceContentsWithScriptResult(), Frame::changeLocation(), and XSLTProcessor. Presumably, some or all of these uses imply strict mode. It's not immediately obvious if this is always correct (and some of these actually call determineParseMode() on their own), but I don't think this patch changes their behavior anyway.
Comment on attachment 8023 [details] proposed fix r=me
Note that this bug apparently fixed Bug 7102 as well.