Bug 5987 – <applet> is broken in xhtml

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Eric Seidel (no email)]

<applet> is broken in xhtml

closeRenderer() is never being called by the xml parser.

[Eric Seidel (no email)]

Created attachment 4985 [details]
Proposed patch

[Eric Seidel (no email)]

Comment on attachment 4985 [details]
Proposed patch

This line should actually probably go after the implicit table node escaping
code right below it in the current patch.  However another question raised by
this patch, is why are we supporting implicit table element construction in
xhtml?

Hyatt or darin should look at this one.

[Eric Seidel (no email)]

Comment on attachment 4985 [details]
Proposed patch

Actually, I think the logic should be re-written to step out of implicit
elements, then call closeRenderer(), then step out to your parent... right now
I bet <applet><tr /> </applet> will fail. :)

[Eric Seidel (no email)]

Comment on attachment 4985 [details]
Proposed patch

Actually, implicit elements (<tbody>) are only created between <table> and
<tr>, so we're safe here.  However the fix would still probably be "more
correct" to do what I mentioned above.

[Eric Seidel (no email)]

Comment on attachment 4985 [details]
Proposed patch

Posting a better patch.

[Eric Seidel (no email)]

Created attachment 4986 [details]
Better patch (correctly handles implicit elements)

[Eric Seidel (no email)]

Comment on attachment 4986 [details]
Better patch (correctly handles implicit elements)

Here is a better patch which correctly handles implicit elements.  Dave or
Darin should take a look at this one.

[Darin Adler]

Comment on attachment 4986 [details]
Better patch (correctly handles implicit elements)

There are three changes here.

One is to call closeRenderer. That looks fine.

Another is to set m_currentNode to the grandparent of the implicit node rather
than the parent of the implicit node. That also seems fine, because we need to
close the element.

The third change is to remove NULL checks. That one worries me a bit, but I
guess we can count on not getting an endElement callback unless we have
successfully started and element. It's worth looking closely at that. What
happens if the startElement fails?

r=me

[Eric Seidel (no email)]

I could add an ASSERT that m_currentNode->parentNode() != 0 if you'd like.  But from what I understand 
this code never should get called in an error case.  I've also tried with some xml docs missing opening 
tags, and not hit any crashes.

[Eric Seidel (no email)]

*** Bug 5835 has been marked as a duplicate of this bug. ***

[Eric Seidel (no email)]

*** Bug 3332 has been marked as a duplicate of this bug. ***

[Lucas Forschler]

Mass moving XML DOM bugs to the "DOM" Component.