Another similar report: http://code.google.com/p/jstree/issues/detail?id=430

This change to Sarissa seems to work.

// _SARISSA_XMLHTTP_PROGID = Sarissa.pickRecentProgID(["Msxml2.XMLHTTP.6.0", "MSXML2.XMLHTTP.3.0", "MSXML2.XMLHTTP", "Microsoft.XMLHTTP"]);

_SARISSA_XMLHTTP_PROGID = Sarissa.pickRecentProgID(["MSXML2.XMLHTTP", "Microsoft.XMLHTTP"]);

Any idea why Msxml2.XMLHTTP.6.0 would error?

So should I close this ticket?

What is the difference between Msxml2.XMLHTTP.6.0 (which errors) and Microsoft.XMLHTTP?

The problem was introduced in jQuery 1.4 because the order of creating xhr was reversed.

What was the reason to reverse the order?

1.4

xhr: window.XMLHttpRequest && (window.location.protocol !== "file:" || !window.ActiveXObject) ?

function() {

return new window.XMLHttpRequest();

} :

function() {

try {

return new window.ActiveXObject("Microsoft.XMLHTTP");

} catch(e) {}

},

1.3

xhr: function() {

return window.ActiveXObject ? new ActiveXObject("Microsoft.XMLHTTP") : new XMLHttpRequest();

},

Further reference

https://jira.jboss.org/jira/browse/RF-8282

http://code.google.com/p/google-web-toolkit/issues/detail?id=3608

http://code.google.com/p/jstree/issues/detail?id=430

More info:

http://code.google.com/p/jstree/issues/detail?id=430#c6

This implies the reference to xhr.abort (not intended as a call) may actually cause a call for only *some* versions of the MS XMLHttpRequest ActiveX control. The try/catch around the replacement of the abort method may be masking the problem.

Do we have a specific version of IE where this is known to happen? Comment 2 says it happened on IE8 but standard $.ajax requests work fine on my test system. Seems like this will be impossible to fix without more info.

We need to know the specific versions of the Microsoft XHR where this occurs in order to reproduce it.

Automatically closed due to 14 days of inactivity.