Bug 13057 - XML parsing errors reported ambiguously by DOMParser.parseFromString
Summary: XML parsing errors reported ambiguously by DOMParser.parseFromString
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 523.x (Safari 3)
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 18210 (view as bug list)
Depends on:
Blocks: 10489
  Show dependency treegraph
 
Reported: 2007-03-13 09:15 PDT by Jesse Costello-Good
Modified: 2023-08-21 15:28 PDT (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Costello-Good 2007-03-13 09:15:27 PDT
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.
Comment 1 Alexey Proskuryakov 2007-03-13 10:47:00 PDT
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.
Comment 2 Jesse Costello-Good 2007-03-13 11:20:04 PDT
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.
Comment 3 Alexey Proskuryakov 2008-04-06 23:56:37 PDT
*** Bug 18210 has been marked as a duplicate of this bug. ***
Comment 4 Lucas Forschler 2019-02-06 09:03:56 PST
Mass moving XML DOM bugs to the "DOM" Component.
Comment 5 Ahmad Saleem 2023-08-13 11:55:38 PDT
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