Bug 91473 - "in body" insertion mode, "any other end tag" step 2.1 is updated
Summary: "in body" insertion mode, "any other end tag" step 2.1 is updated
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Kwang Yul Seo
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-17 00:12 PDT by Kwang Yul Seo
Modified: 2012-07-17 15:24 PDT (History)
3 users (show)

See Also:


Attachments
Patch (2.91 KB, patch)
2012-07-17 01:02 PDT, Kwang Yul Seo
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kwang Yul Seo 2012-07-17 00:12:34 PDT
Eric filed a bug with HTML5:

"in body" insertion mode, "any other end tag", step 2.2 seems wrong.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10080


Since then the HTML5 spec is updated to change the 'end tag' processing to not imply its own end tag, since that makes no sense.

http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inbody

2.1 Generate implied end tags. 

-> 

2.1 Generate implied end tags, except for elements with the same tag name as the token.
Comment 1 Kwang Yul Seo 2012-07-17 01:02:45 PDT
Created attachment 152710 [details]
Patch
Comment 2 Eric Seidel (no email) 2012-07-17 02:12:33 PDT
Comment on attachment 152710 [details]
Patch

OK.
Comment 3 WebKit Review Bot 2012-07-17 02:59:49 PDT
Comment on attachment 152710 [details]
Patch

Clearing flags on attachment: 152710

Committed r122831: <http://trac.webkit.org/changeset/122831>
Comment 4 WebKit Review Bot 2012-07-17 02:59:53 PDT
All reviewed patches have been landed.  Closing bug.
Comment 5 Adam Barth 2012-07-17 10:47:23 PDT
Is there any observable change in behavior with this change?  If so, we should have added a test.
Comment 6 Kwang Yul Seo 2012-07-17 15:07:04 PDT
(In reply to comment #5)
> Is there any observable change in behavior with this change?  If so, we should have added a test.

As I mentioned briefly in the change log, there is no observable change in behavior. This patch reduces parse errors, but that's not observable because HTMLTreeBuilder::parseError(AtomicToken&) is just an empty marker.
Comment 7 Adam Barth 2012-07-17 15:24:24 PDT
Thanks!