Bug 13057 – XML parsing errors reported ambiguously by DOMParser.parseFromString

• Status: NEW
• Component: DOM

[Jesse Costello-Good]

For developers trying to figure out whether the parsing of an XML string succeeder or not, the way that DOMParser reports errors as of r20136 is not very useful. 

A month ago, the following code would identify an error:

var doc = (new DOMParser()).parseFromString(xml);
var errorNode = (new XPathEvaluator()).evaluate("//parsererror//div", doc).iterateNext();
if (errorNode) {
    // Error!
}

However, now it appears that the parsererror node is an HTMLElement rather than an Element and so the XPath query does not select it. The returned document and its root node are still Document and Element, respectively, so it is not possible to use getElementsByTagName either. 

The only way I can figure to identify an error is to traverse the entire returned document and look for either HTMLElements or a node called parsererror and then look for a div contained in that. 

I'd like to suggest that Firefox handles this in a much more elegant manner. The same method in Firefox indicates a parsing error by returning a document with a root element <parsererror xmlns="http://www.mozilla.org/newlayout/xml/parsererror.xml">. There are no nested elements within the document element, only the text description of the parse error. In addition to this being very easy for a developer to identify, it is also unambiguous because of the namespaceURI. 

I hope this can make it into Safari 3.

[Alexey Proskuryakov]

I can confirm that the DOMParser error document does not match Firefox. I doubt that changing it is appropriate for the stabilization period, though.

As for the change in behavior from the previous month - it was actually a bugfix in XPath. Since our error document is an XHTML one (which is apparently different from Firefox), you need to use the XHTML namespaces in the XPath expression:

function nsResolver(prefix) {
    if (prefix == "x")
        return "http://www.w3.org/1999/xhtml";
    return null;
}

var errorNode = (new XPathEvaluator()).evaluate("//x:parsererror//x:div", doc, nsResolver).iterateNext();

Of course, the code above will cease to work when/if we fix the error document to match Firefox.

[Jesse Costello-Good]

Thanks for the namespace related fix. That will work for me for now. I still recommend using a namespace owned by webkit to avoid any ambiguities, however unlikely they may be.

[Alexey Proskuryakov]

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

[Lucas Forschler]

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

[Ahmad Saleem]

I think for this we have WPT: https://wpt.fyi/results/domparsing/DOMParser-parseFromString-xml.html?label=master&label=experimental&aligned=&q=domparsing

CCing @Anne % @Ryosuke