Closed Bug 578568 Opened 15 years ago Closed 15 years ago

[HTML5] Minefield builds the wrong DOM for "<a>1<button>2</a>3</button>"

Categories

(Core :: DOM: HTML Parser, defect, P2)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla2.0b7
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: eric, Assigned: hsivonen)

References

Details

(Keywords: compat)

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.458.1 Safari/534.3 Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; en-US; rv:2.0b2pre) Gecko/20100712 Minefield/4.0b2pre GTB7.0 Minefield builds the wrong DOM for "<a>1<button>2</a>3</button>" Expected: | <html> | <head> | <body> | <a> | "1" | <button> | "23" Minefield: | <html> | <head> | <body> | <a> | "1" | <button> | "2" | "3" Maybe I'm reading the spec wrong, but I think Gecko has a bug here. Reproducible: Always
Assignee: nobody → hsivonen
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.
OK, now I"m confused. Somehow existing WebKit (non-html5) matches Minefield's behavior. Maybe I'm reading the spec wrong.
> because <button> is a scope marker. Turns out that part of the spec was not necessarily compatible with reality, and the spec was changed so that this is no longer the case. See bug 558302 and http://www.w3.org/Bugs/Public/show_bug.cgi?id=9496 But note also bug 569528.
OS: Mac OS X → All
Hardware: x86 → All
Summary: Minefield builds the wrong DOM for "<a>1<button>2</a>3</button>" → [HTML5] Minefield builds the wrong DOM for "<a>1<button>2</a>3</button>"
Yeah, the fix for bug 558302 wasn't all that great.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
blocking2.0: --- → ?
Seems like something that needs fixed for Firefox 4.
blocking2.0: ? → betaN+
Keywords: compat
Fixed by the patch for bug 569528. Test case will land as part of bug 559023.
Depends on: 569528
Depends on: 559023
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b7
You need to log in before you can comment on or make changes to this bug.