Bug 7413 – REGRESSION: [DOMRange markupString] produces invalid XML (opening tags are self-closing)

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: DOM

[Alexey Proskuryakov]

When reproducing bug 5385, I've noticed that [DOMRange markupString] produces incorrect results. Here is what I observe, followed by the original steps to reproduce.

-----------------------------------------------
I can see that the ToT result is badly broken, tags are not
opened and closed correctly:
<title/>Why You Should Care</title>
...
<surname/>Raymond</surname>
...etc.
-----------------------------------------------
To reproduce:
Load xml-file into webview (I used http://www.catb.org/~esr/writings/cathedral-bazaar/
introduction.xml)
- Select the preface-node  (=>selectedItem)

(I added the following test-code to the DOMTreeViewer example, in DOMDatasource.m:119 and clicked 
around)

	DOMRange *myRange = [[[_webView mainFrame] DOMDocument] createRange];
	[myRange selectNode: selectedItem];
	NSLog( [myRange markupString]);

[Darin Adler]

What's the evidence that this is a regression?

[Darin Adler]

Oh, sorry, I see.

[Darin Adler]

Here's how it's supposed to work: the function shouldSelfClose in markup.cpp should return false for the <title> element. It's not an HTML <title> element, so htmlForbidsEndTag and isHTMLElement should be false. It's not an HTML document, so isHTMLDocument should be false. It does have a child node, so hasChildNodes should be true. So it should fall through to the end of the function and return false. And because of that, there should be no "/>" at the end of the tag.

[Darin Adler]

Created attachment 6720 [details]
patch to improve logic, not sure if it fixes the bug since I can't reproduce

[Darin Adler]

When I tested with the attached patch, a couple layout test results changed for the better.

[Alexey Proskuryakov]

I could have sweared that I have checked and double-checked that this was a regression, but now I'm getting the opposite results - 10.4.4 WebKit fails, but ToT works correctly. The only explanation I can find is that I was wrong, despite double-checking. Sorry.

[Darin Adler]

Not a problem at all. Closing the bug. I still want to land the patch though. I'll write a new bug for that.

[Lucas Forschler]

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