RESOLVED FIXED 42233
HTMLTreeBuilder needs to update to match new spec behavior for <button> 
https://bugs.webkit.org/show_bug.cgi?id=42233
Summary HTMLTreeBuilder needs to update to match new spec behavior for <button>
Eric Seidel (no email)
Reported 2010-07-13 22:24:56 PDT
Minefields "<a>1<button>2</a>3</button>" behavior is wrong, update results
Attachments
Patch (11.41 KB, patch)
2010-07-21 14:47 PDT, Adam Barth 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1 2010-07-13 22:28:50 PDT
Actually, I now realize that the LegacyHTMLTreeBuilder matches minefield's behavior. Maybe I read the HTML5 spec wrong? I've filed a bug with Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=578568
Eric Seidel (no email)
Comment 2 2010-07-13 22:32:04 PDT
I'm still pretty certain that Minefield's behavior violates HTML5. As far as I can tell, when you hit the </a> the adoption agency algorithm does not run because of: "If there is no such node, or, if that node is also in the stack of open elements but the element is not in scope, then this is a parse error; ignore the token, and abort these steps." There is an <a> in the open elements, but its not in scope, because <button> is a scope marker. So the </a> is just ignored, and the 3 ends up inside <button> and is coalesced.
Eric Seidel (no email)
Comment 3 2010-07-13 22:33:04 PDT
Ahha. The spec has changed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9496
Eric Seidel (no email)
Comment 4 2010-07-13 22:34:14 PDT
See also: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9829
Eric Seidel (no email)
Comment 5 2010-07-13 22:50:01 PDT
We need to implement this diff: http://html5.org/tools/web-apps-tracker?from=5031&to=5032
Adam Barth
Comment 6 2010-07-21 14:47:33 PDT
Created attachment 62232 [details] Patch
Eric Seidel (no email)
Comment 7 2010-07-21 15:46:33 PDT
Comment on attachment 62232 [details] Patch There was discussion between Henri and Ian just today about rolling out this spec change, making me wary of trying to do anything here yet.
Adam Barth
Comment 8 2010-07-21 15:55:31 PDT
I think we should track the spec. If the spec changes again, we can change the code again too.
Eric Seidel (no email)
Comment 9 2010-07-21 17:31:02 PDT
Comment on attachment 62232 [details] Patch OK. There was talk of reverting this change in the spec... but we can always revert this revision too. Sigh.
Adam Barth
Comment 10 2010-07-21 18:00:54 PDT
Comment on attachment 62232 [details] Patch Clearing flags on attachment: 62232 Committed r63868: <http://trac.webkit.org/changeset/63868>
Adam Barth
Comment 11 2010-07-21 18:01:01 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.