$.parseXML has non-standardized behavior for IE9+ and other browsers

Reported by:	anonymous	Owned by:	anonymous
Priority:	undecided	Milestone:	None
Component:	unfiled	Version:	1.9.1
Keywords:		Cc:
Blocked by:		Blocking:

Description

This relates to #13276, but I am uncertain if a proper fix was committed to resolve the issues.

With the addition of the DOMParser object to IE9+, the $.parseXML interface has now semi-broken for IE9 compared to previous versions of IE or other browsers.

http://jsfiddle.net/8Zksb/

$.parseXML (in other DOMParser browers or pre-IE9 browsers using ActiveXObject) will return an XML based document object -- this object can support XPath calls using the selectNodes/selectSingleNodes (in IE).

In IE9, the returned type is an HTML Document object which does NOT support these sorts of XPath expressions.

The simple fix that I have been able to come up with has been to flip the feature detection of ActiveXObject vs window.DOMParser in the parseXML function (or simply skip the window.DOMParser usage for msie type browsers and fall back to ActiveXObject in all IE browers).

Attachments (0)

Change History (4)

Changed April 04, 2013 03:01AM UTC by m_gol comment:1

This would, on the other hand, cause different behavior for IE9 in jQuery 2.x since no ActiveXObject is used in 2.x code base.

Changed April 04, 2013 07:43PM UTC by dmethvin comment:2

owner:	→ anonymous
status:	new → pending

Also, #13276 would be broken by going back to the ActiveX version. Since you have jQuery at your disposal is there any reason to not use its selection and traversal methods? If you need .selectSingleNode() for some compat reason you can retrieve the text and parse it yourself as you mentioned.

Changed April 04, 2013 08:14PM UTC by anonymous comment:3

status:	pending → new

My main concern was that it is simply inconsistent behavior across browsers (and changes behavior from IE8 to IE9). It seems to me that a $.parseXML on a string should return the same type of object that would be returned if I perform a $.ajax() call or a hand-rolled XMLHttpRequest call.

Why would using the ActiveXObject to simply parse the XML string break #13276? Does it break in versions of IE prior to IE9? If I performed a non-jQuery ajax call to retrieve an XML based document object then called into the same methods would they not work? If so, that seems like it would be a problem with the changes introduced in that changeset...

Nevertheless, if you feel it is proper behavior for IE9+ (when parsing an XML string) to return a different object type than you would retrieve on an ajax call while the other mainstream browsers (Firefox/Chrome) return the same object type then I have can accept that and work around it.

Changed April 04, 2013 08:24PM UTC by dmethvin comment:4

resolution:	→ wontfix
status:	new → closed

The problem is that the ActiveX-based parser (and the .responseXML of the native IE9 XHR) does not return the right kind of document object. That means you can't, for example, create an XML document with $.parseXML() and move nodes to/from a document gotten from an ajax call. It's hard if not impossible to work around #13276 whereas this problem isn't bad at all.

And again, we go through a lot of hassle throughout jQuery so that selection, traversing, and manipulation work on these crazy XML documents no matter the source. If you really need the old document and methods for compat reasons it's not hard to get it.

Side navigation