RESOLVED FIXED 15136
HTML5 spec violation: </h1> doesn't end <h3> element in Webkit 
https://bugs.webkit.org/show_bug.cgi?id=15136
Summary HTML5 spec violation: </h1> doesn't end <h3> element in Webkit
Robert Blaut
Reported 2007-09-03 04:57:16 PDT
1. Go to the page http://skapiec.pl 2. Notice a broken layout. This is caused by in incorrect error handling in Safari 3. The below code causes this behavior. Notice opening h3 tag and closing h1 tag. <h3 id="logo"><a title="Sk±piec.pl - Strona g³ówna" href="/"><img src="http://pic.skapiec.pl/_i/img2/logo.png" alt="Skapiec.pl - kupuj najtaniej"/></a></h1> I've created minimal test case for this bug: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pl" lang="pl"> <head> <title>Test case for error handling in Safari 3 - found bug on http://skapiec.pl</title> <style type="text/css" media="all"> #test1 { float:left; background-color:green; width:100px; height: 100px;} #test2 { float:right; background-color:blue; width:100px; height: 100px;} p {border: 1px solid blue;} </style> </head> <body> <h3 id="test1"></h1> <div id="test2"></div> <p>There should be two boxes on the page - green and blue. The text should be placed between these two boxes.</p> </body> </html> Expected result: This code should render two boxes on the page - green and blue and the text on the page should be placed between these two boxes. Actual result. Blue box covers the green one. And the text is rendered below blue box. Other tested browsers: Firefox 2, Opera 9 and Internet Explorer 7 have no problem with it. Only Safari 3 renders it incorrectly.
Attachments
Minimal test case for the bug (738 bytes, text/html)
2007-09-03 04:59 PDT, Robert Blaut 		no flags
Details
screenshot of testcase on Mac Safari 5.0.1 versus ToT (299.21 KB, image/png)
2010-09-01 01:47 PDT, Matthew Willis (lilmatt) 		no flags
Details
Test case for this bug (17.42 KB, patch)
2010-09-01 03:18 PDT, Matthew Willis (lilmatt) 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Robert Blaut
Comment 1 2007-09-03 04:59:12 PDT
Created attachment 16185 [details] Minimal test case for the bug
David Kilzer (:ddkilzer)
Comment 2 2007-09-03 10:50:56 PDT
Looks like an HTML parsing issue. Look at the source in Hixie's Live DOM Viewer: http://software.hixie.ch/utilities/js/live-dom-viewer/ In Firefox 2.0.0.6, the open <h3> tag is closed before the <div> tag. In Safari (both ToT WebKit and Safari 2.0.4 with original WebKit), the <div> tag is a child of the <h3> tag.
mitz
Comment 3 2007-09-03 11:08:09 PDT
(In reply to comment #2) > Looks like an HTML parsing issue. Yeah, I just thought those traditionally went under "Page Loading" :-)
David Kilzer (:ddkilzer)
Comment 4 2007-09-03 11:10:20 PDT
(In reply to comment #3) > (In reply to comment #2) > > Looks like an HTML parsing issue. > Yeah, I just thought those traditionally went under "Page Loading" :-) Does the "Component" text need to be updated then? :) http://bugs.webkit.org/describecomponents.cgi?product=WebKit
mitz
Comment 5 2007-09-03 11:14:03 PDT
(In reply to comment #4) > Does the "Component" text need to be updated then? :) > > http://bugs.webkit.org/describecomponents.cgi?product=WebKit No, but I learned something new. Thanks!
Robert Blaut
Comment 6 2008-02-25 04:49:43 PST
<rdar://problem/5762882>
Robert Blaut
Comment 7 2008-02-27 06:25:02 PST
HTML5 says: "An end tag whose tag name is one of: "h1", "h2", "h3", "h4", "h5", "h6" If the stack of open elements has in scope an element whose tag name is one of "h1", "h2", "h3", "h4", "h5", or "h6", then generate implied end tags. Now, if the current node is not an element with the same tag name as that of the token, then this is a parse error. If the stack of open elements has in scope an element whose tag name is one of "h1", "h2", "h3", "h4", "h5", or "h6", then pop elements from the stack until an element with one of those tag names has been popped from the stack." So any of the </h1 > - </h6> tags should close mismatched <h1> - <h6> tags. All of tested engines Trident (IE6), Gecko and Presto do it. HTML5lib also properly closes the tag: <h3 id=test1> </h3> <div id=test2> </div> <p> There should be two boxes on the page - green and blue. The text should be placed between these two boxes. </p>
Robert Blaut
Comment 8 2008-03-17 04:18:18 PDT
*** Bug 17846 has been marked as a duplicate of this bug. ***
Bertrand Presles
Comment 9 2008-03-25 14:32:51 PDT
Another website that doesn't display at all in Safari (even with latest Webkit nightly): http://www.spa.asso.fr/ I don't know if it's for the similar reasons...
Robert Blaut
Comment 10 2008-07-28 03:55:04 PDT
The reported site was corrected so the bug isn't visible any more. Cleared URL field.
Bertrand Presles
Comment 11 2008-07-28 06:10:04 PDT
I don't know if you mean that site: http://www.spa.asso.fr by "The reported site was corrected so the bug isn't visible any more.", but at least here (Safari 3.1.2) the site is still totally blank.
Robert Blaut
Comment 12 2008-07-28 06:15:16 PDT
(In reply to comment #11) > I don't know if you mean that site: http://www.spa.asso.fr by "The reported > site was corrected so the bug isn't visible any more.", but at least here > (Safari 3.1.2) the site is still totally blank. > I mean initially reported page skapiec.pl. www.spra.asso.fr has different issue tracked in bug 18124.
Matthew Willis (lilmatt)
Comment 13 2010-09-01 01:47:32 PDT
Created attachment 66180 [details] screenshot of testcase on Mac Safari 5.0.1 versus ToT While this is still a bug in Mac Safari 5.0.1 (6533.17.8) it appears to no longer be failing on ToT.
Matthew Willis (lilmatt)
Comment 14 2010-09-01 01:49:56 PDT
(In reply to comment #13) > Created an attachment (id=66180) [details] Left is Safari 5.0.1 -- WebKit 533.17.8 Right is 534.7+
Robert Blaut
Comment 15 2010-09-01 02:41:53 PDT
The bug was fixed by a new HTML5 parser enabled in WebKit (especially HTML5 tree builder: http://trac.webkit.org/changeset/64712)
Matthew Willis (lilmatt)
Comment 16 2010-09-01 03:18:49 PDT
Created attachment 66188 [details] Test case for this bug
Matthew Willis (lilmatt)
Comment 17 2010-09-01 03:42:11 PDT
Comment on attachment 66188 [details] Test case for this bug I hesitate to request the commit bot because of the svn properties in the diff. Does it know how to handle that?
Alexey Proskuryakov
Comment 18 2010-09-01 12:16:11 PDT
Reopening for tests.
Alexey Proskuryakov
Comment 19 2010-09-01 12:17:51 PDT
Comment on attachment 66188 [details] Test case for this bug I think that svn properties will be ignored when applying the patch, which should not be a problem. Thanks for making the test!
WebKit Commit Bot
Comment 20 2010-09-01 13:31:35 PDT
Comment on attachment 66188 [details] Test case for this bug Rejecting patch 66188 from commit-queue. Failed to run "['WebKitTools/Scripts/run-webkit-tests', '--no-launch-safari', '--exit-after-n-failures=1', '--wait-for-httpd', '--ignore-tests', 'compositing,media', '--quiet']" exit_code: 1 Running build-dumprendertree Compiling Java tests make: Nothing to be done for `default'. Running tests from /Users/eseidel/Projects/CommitQueue/LayoutTests Testing 20894 test cases. fast/forms/implicit-submission.html -> failed Exiting early after 1 failures. 7570 tests run. 252.22s total testing time 7569 test cases (99%) succeeded 1 test case (<1%) had incorrect layout Full output: http://queues.webkit.org/results/3941037
Alexey Proskuryakov
Comment 21 2010-09-01 14:15:18 PDT
Comment on attachment 66188 [details] Test case for this bug This (test-only) patch shouldn't have affected that test, let's try again.
Adam Barth
Comment 22 2010-09-01 14:24:05 PDT
This test should probably have gone in fast/parser, but I don't think it's a big deal.
WebKit Commit Bot
Comment 23 2010-09-01 19:57:36 PDT
Comment on attachment 66188 [details] Test case for this bug Clearing flags on attachment: 66188 Committed r66635: <http://trac.webkit.org/changeset/66635>
WebKit Commit Bot
Comment 24 2010-09-01 19:57:43 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.