RESOLVED FIXED Bug 8626
Strict mode erroneously triggered by a broken comment 
https://bugs.webkit.org/show_bug.cgi?id=8626
Summary Strict mode erroneously triggered by a broken comment
Matt Gough
Reported 2006-04-27 01:32:03 PDT
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'.
Attachments
A reduction (209 bytes, text/html)
2006-04-27 01:44 PDT, Matt Gough 		no flags
Details
proposed fix (3.33 KB, patch)
2006-04-28 11:50 PDT, Alexey Proskuryakov 		mjs: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Matt Gough
Comment 1 2006-04-27 01:44:13 PDT
Created attachment 7991 [details] A reduction
Alexey Proskuryakov
Comment 2 2006-04-27 21:43:58 PDT
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.
Alexey Proskuryakov
Comment 3 2006-04-28 11:50:43 PDT
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>.
Darin Adler
Comment 4 2006-04-28 17:13:07 PDT
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?
Alexey Proskuryakov
Comment 5 2006-04-28 22:40:26 PDT
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.
Maciej Stachowiak
Comment 6 2006-05-04 13:32:03 PDT
Comment on attachment 8023 [details] proposed fix r=me
David Kilzer (:ddkilzer)
Comment 7 2006-07-11 03:40:05 PDT
Note that this bug apparently fixed Bug 7102 as well.
Note You need to log in before you can comment on or make changes to this bug.