Summary: | Strict mode erroneously triggered by a broken comment | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Matt Gough <matt> | ||||||
Component: | DOM | Assignee: | Alexey Proskuryakov <ap> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | ap, darin | ||||||
Priority: | P2 | ||||||||
Version: | 418.x | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.4 | ||||||||
URL: | http://mayan.tzo.com:888/dreamsp/dreamain.htm | ||||||||
Attachments: |
|
Description
Matt Gough
2006-04-27 01:32:03 PDT
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
|