2010-06-11 Eric Seidel <eric@webkit.org>
authoreric@webkit.org <eric@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 11 Jun 2010 19:37:27 +0000 (19:37 +0000)
committereric@webkit.org <eric@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 11 Jun 2010 19:37:27 +0000 (19:37 +0000)
        Reviewed by Adam Barth.

        tables/mozilla/bugs/bug1188.html needlessly depends on HTML Parser text node handling
        https://bugs.webkit.org/show_bug.cgi?id=40485

        The old HTMLTokenizer handled invalid close tags like "< /A>" as part
        of the lexing step.  The HTML5 parser specification dictates that
        the tokenization/lexing step is to output each character token in sequence
        and that the parser is to insert emitted character tokens into the last
        parser-created text node.  In our current HTML5Lexer-with-old-HTMLParser
        setup, we gather up character tokens and output them all in one bunch
        (to match the expectations of the old parser).

        In the case of "foo< /A>" the HTML5Lexer sees the '<', switched out of the
        "data" state and emits all pending characters assuming the start of a close tag.
        When it sees the ' ' it switches back to the "data" state.  The HTML5Lexer
        expects that the parser will coalesce the separate characters it emitted
        into one text node.  Since we haven't implemented the parser side of the
        HTML5 spec, for now we don't.  This is a known issue we will address after
        enabling the HTML5Lexer, as we start to write an HTML5-compliant parser.

        This text-node-coalescing behavior is already tested by numerous html5lib
        tests, however this was the only layout test which hit this quirk.  I've
        added yet another html5lib test of this exact case just for good measure.

        * html5lib/resources/webkit01.dat:
         - Add a test of this exact case to make sure we don't miss it when implementing
           an HTML5-compliant parser.
        * tables/mozilla/bugs/bug1188.html:
         - Replace "< /A>" with "&lt /A>" to avoid hitting this lexing quirk.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@61033 268f45cc-cd09-0410-ab3c-d52691b4dbfc

LayoutTests/ChangeLog
LayoutTests/html5lib/resources/webkit01.dat
LayoutTests/tables/mozilla/bugs/bug1188.html

index 2a7e8ca..46e24a0 100644 (file)
@@ -1,3 +1,36 @@
+2010-06-11  Eric Seidel  <eric@webkit.org>
+
+        Reviewed by Adam Barth.
+
+        tables/mozilla/bugs/bug1188.html needlessly depends on HTML Parser text node handling
+        https://bugs.webkit.org/show_bug.cgi?id=40485
+
+        The old HTMLTokenizer handled invalid close tags like "< /A>" as part
+        of the lexing step.  The HTML5 parser specification dictates that
+        the tokenization/lexing step is to output each character token in sequence
+        and that the parser is to insert emitted character tokens into the last
+        parser-created text node.  In our current HTML5Lexer-with-old-HTMLParser
+        setup, we gather up character tokens and output them all in one bunch
+        (to match the expectations of the old parser).
+        
+        In the case of "foo< /A>" the HTML5Lexer sees the '<', switched out of the
+        "data" state and emits all pending characters assuming the start of a close tag.
+        When it sees the ' ' it switches back to the "data" state.  The HTML5Lexer
+        expects that the parser will coalesce the separate characters it emitted
+        into one text node.  Since we haven't implemented the parser side of the
+        HTML5 spec, for now we don't.  This is a known issue we will address after
+        enabling the HTML5Lexer, as we start to write an HTML5-compliant parser.
+
+        This text-node-coalescing behavior is already tested by numerous html5lib
+        tests, however this was the only layout test which hit this quirk.  I've
+        added yet another html5lib test of this exact case just for good measure.
+
+        * html5lib/resources/webkit01.dat:
+         - Add a test of this exact case to make sure we don't miss it when implementing
+           an HTML5-compliant parser.
+        * tables/mozilla/bugs/bug1188.html:
+         - Replace "< /A>" with "&lt /A>" to avoid hitting this lexing quirk.
+
 2010-06-11  Dmitry Titov  <dimich@chromium.org>
 
         Unreviewed, update Chromium test expectations.
index d633c6e..544da9e 100644 (file)
@@ -199,3 +199,13 @@ console.log("FOO<span>BAR</span>BAZ");
 |     <rdar:>
 |       6869687=""
 |       problem=""
+
+#data
+<A>test< /A>
+#errors
+#document
+| <html>
+|   <head>
+|   <body>
+|     <a>
+|       "test< /A>"
index 473d195..ad11d48 100644 (file)
@@ -17,7 +17,7 @@ HEIGHT=42 BORDER=0 ALT=Netcenter>
 VALUE=Search><BR>
                 <small><A 
 HREF="http://info.netscape.com/fwd/hom10scla/http://exciteclassifieds.netscape.c
-om/cgi-cls/display.exe?partner=netcenter&path=class&template=none&">Classifieds<
+om/cgi-cls/display.exe?partner=netcenter&path=class&template=none&">Classifieds&lt;
 /A> &nbsp; <A HREF="/escapes/search/netsearchv0.html?cp=hom10snet">Net 
 Search</A> &nbsp; <A HREF="/directory/index.html?cp=hom10sdir">Find Web 
 Sites</A> 
@@ -59,7 +59,7 @@ db00.html>Instant Messenger</A> - <A
 HREF="/qwest/long_distance/index.html?cp=hom10yqst">Long Distance</A> - <A 
 HREF="http://info.netscape.com/fwd/hom10ymem/http://form.netscape.com/members/in
 dex.html">Members</A> - <A 
-HREF=http://info.netscape.com/fwd/hom10ymal/http://webmail.netscape.com>WebMail<
+HREF=http://info.netscape.com/fwd/hom10ymal/http://webmail.netscape.com>WebMail&lt;
 /A></small>
         </TD>
 </TR>