This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Created attachment 972 [details] Testcase The attached test case gets stuck in ScriptDataDoubleEscapedState which seems incorrect. IE7-9: PASS SF5: PASS OP11: PASS FF3.6: PASS FF4: FAIL CR10-12: FAIL Filed in WebKit as https://bugs.webkit.org/show_bug.cgi?id=57407
Note: This bug affects Bugzilla, so be careful copy/pasting the string around in this page or you might hose the bug.
Actually the title of this bug is misleading, the "</script>" gets us out of ScriptDataDoubleEscapedState and back into ScriptDataEscapedState. I'm still looking into it, but maybe the bug is that we shouldn't go into ScriptDataDoubleEscapedState in the first place.
It's known that there exists some sites on the Web where the spec gets stuck inside a script. That's the price of never reparsing. Is this breaking a top site that you have been unable to evangelize? With Firefox, the script states have been a wild success beyond my expectations. Exactly one case of site breakage has reached me on b.m.o and that site was successfully evangelized. With the data presented so far, I'd WONTFIX this. To the extent this affects Bugzilla itself, it's a bug in Bugzilla, although I thought the bug was already fixed in upstream Bugzilla. In general, any Web app that includes untrusted strings as string literals in inline scripts MUST escape < as \u003C to be safe. (That's the simplest way to deal with <!--, <script> and </script> all in one go.)
Also note that you'll never get all possible cases "right" without including JavaScript and VBScript parsers as part of the HTML tokenizer, so it's kinda useless to be able to point to one more case that "fails".
Tony probably knows more of the details, but my understanding is that this issue manifests itself in one of Google's web site. We can certainly ask those folks if they'd be willing to work around the issue.
(In reply to comment #5) > Tony probably knows more of the details, but my understanding is that this > issue manifests itself in one of Google's web site. We can certainly ask those > folks if they'd be willing to work around the issue. In that case, I think this should be WONTFIX+evang.
I agree that this should be WONTFIX. The current spec is as web compatible as it gets without doing reparsing.
Thanks for the explanations. I've mentioned your escaping suggestion to the webmaster. Does anyone have a bugzilla contact to do the same?
I believe the Bugzilla bug was https://bugzilla.mozilla.org/show_bug.cgi?id=503980 Is there still another bug of that nature in Bugzilla itself?
Note that a Web page that runs into this will be invalid, so authors can avoid this problem by using the validator to check their pages. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: per comments above
mass-move component to LC1