[Bug 22233] New: [HTML]: I can't find the rules which specify real-world parsing of <body><script>&amp;

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22233

            Bug ID: 22233
           Summary: [HTML]: I can't find the rules which specify
                    real-world parsing of <body><script>&amp;
    Classification: Unclassified
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec
          Assignee: dave.null@w3.org
          Reporter: alan.christopher.jenkins@googlemail.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-admin@w3.org,
                    public-html-wg-issue-tracking@w3.org

AFAICS the tokenizer is only switched to "script data state" from the "in head"
insertion mode.

However real-world browsers also switch to "script data state" from <script>
inside <body>.  E.g. Firefox 21.0 with this test page:

<!doctype html>
<body><!-- behaviour is identical if <body> is removed -->
<script>alert('&amp;')</script>

The result is "&amp;".  But AFAICS the spec implies this (non-conforming) page
should result in "&".  (Which violates the principle of least surprise, at
least).

My understanding was that this was the real-world behaviour on all major
browsers.  And if the spec is in variation then no major browser is conforming,
which is an obstacle to standardization.

Am I right about the behaviour specified by HTML5?  And major browsers other
than Firefox?  If so, does the spec need to be changed?

This thought was provoked after looking at how <svg><script> works in HTML
syntax. 
http://security.stackexchange.com/questions/36701/why-does-this-xss-vector-work-in-svg-but-not-in-html

I recently came across this particular tag soup in ci-Bonfire.  Example page
http://eposure.com/

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Sunday, 2 June 2013 12:57:25 UTC