Bug 15136 - HTML5 spec violation: </h1> doesn't end <h3> element in Webkit
Summary: HTML5 spec violation: </h1> doesn't end <h3> element in Webkit
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 523.x (Safari 3)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: HasReduction, InRadar
: 17846 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-09-03 04:57 PDT by Robert Blaut
Modified: 2010-09-01 19:57 PDT (History)
8 users (show)

See Also:


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 Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Blaut 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.
Comment 1 Robert Blaut 2007-09-03 04:59:12 PDT
Created attachment 16185 [details]
Minimal test case for the bug
Comment 2 David Kilzer (:ddkilzer) 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.

Comment 3 mitz 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" :-)
Comment 4 David Kilzer (:ddkilzer) 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

Comment 5 mitz 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!
Comment 6 Robert Blaut 2008-02-25 04:49:43 PST
<rdar://problem/5762882>
Comment 7 Robert Blaut 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>
Comment 8 Robert Blaut 2008-03-17 04:18:18 PDT
*** Bug 17846 has been marked as a duplicate of this bug. ***
Comment 9 Bertrand Presles 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... 
Comment 10 Robert Blaut 2008-07-28 03:55:04 PDT
The reported site was corrected so the bug isn't visible any more. Cleared URL field.
Comment 11 Bertrand Presles 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.
Comment 12 Robert Blaut 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.
Comment 13 Matthew Willis (lilmatt) 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.
Comment 14 Matthew Willis (lilmatt) 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+
Comment 15 Robert Blaut 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)
Comment 16 Matthew Willis (lilmatt) 2010-09-01 03:18:49 PDT
Created attachment 66188 [details]
Test case for this bug
Comment 17 Matthew Willis (lilmatt) 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?
Comment 18 Alexey Proskuryakov 2010-09-01 12:16:11 PDT
Reopening for tests.
Comment 19 Alexey Proskuryakov 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!
Comment 20 WebKit Commit Bot 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
Comment 21 Alexey Proskuryakov 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.
Comment 22 Adam Barth 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.
Comment 23 WebKit Commit Bot 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>
Comment 24 WebKit Commit Bot 2010-09-01 19:57:43 PDT
All reviewed patches have been landed.  Closing bug.