Correctly handle case where fake XHR returns invalid XML #50
Conversation
When DOMParser fails to parse a XML response, correctly set responseXML to null. Also, use the JSDOM implementation of DOMParser when running the test suite as xmldom would not handle error cases in a correct manner.
| } | ||
| var xmlDoc = new window.ActiveXObject("Microsoft.XMLDOM"); | ||
| xmlDoc.async = "false"; | ||
| xmlDoc.loadXML(text); | ||
| return xmlDoc; | ||
| return xmlDoc.parseError.errorCode !== 0 |
There was a problem hiding this comment.
This is what MSDN says should happen, but I have no way of testing if that is actually correct unfortunately.
There was a problem hiding this comment.
Just got my hands on IE11 and it seems like this actually works as advertised. Alternatively it looks like the loadXML call returns true or false depending on if parsing worked, but since the above is what's documented, I'd stick to it.
|
Seems to break for some. Could you have a look at #54? |
|
I am using |
|
Whoops, that is unfortunate, sorry for the inconvenience @bafolts. So what's happening is the following: in order to fix #25 it was needed to somehow find out if there is a The question is now how do we fix situations like this:
Let me know what you think @fatso83 so I can open a PR for this. |
When DOMParser fails to parse a XML response, correctly set
responseXML to null. Also, use the JSDOM implementation of
DOMParser when running the test suite as xmldom would not
handle error cases in a correct manner.
Solves #25. It looks like the
xmldomparser does not create a<parsererror>node correctly, so it cannot be used in the tests. Since JSDOM also knows aboutDOMParserit in the meantime I would guess it's ok to use it for doing that instead as it's a dependency anyways.I'm also sorry for all the package-lock noise, I'm on
6.1.0and didn't do much but uninstallingxmldom