W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2009

[Bug 7917] New: document.close() should attempt to tokenize

From: <bugzilla@wiggum.w3.org>
Date: Wed, 14 Oct 2009 11:56:51 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-7917-2486@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7917

           Summary: document.close() should attempt to tokenize
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec bugs
        AssignedTo: dave.null@w3.org
        ReportedBy: hsivonen@iki.fi
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org, public-html@w3.org


It seems that the current spec definition of document.close() matches Gecko.
However, Trident, WebKit and Presto all try to tokenize synchronously on
document.close() in addition to inserting the EOF character in the stream.

Presto seems to tokenize to EOF. WebKit tokenizes until EOF or the earliest
external-script </script> whichever comes first.

Trident tokenizes but I'm not sure how far. (I gave up testing before I found
out.)

Since 3 out of 4 tokenize at least somewhat, I think document.write() should
attempt to tokenize. However, I think it should bail out if the tokenization
causes the parser to block, since that's more implementable in Gecko than what
Presto does.

Live DOM URLs of interest:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/276
Shows that Gecko doesn't tokenize but WebKit and Presto tokenize.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/277
Shows that Trident tokenizes.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/278
Shows that WebKit bails out but Presto doesn't.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 14 October 2009 11:56:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 14 October 2009 11:56:54 GMT