Simplify XHR detection

[FarSeeing]

This is the XMLHttpRequest object detection code:

https://github.com/jquery/jquery/blob/master/src/ajax/xhr.js

jQuery.ajaxSettings.xhr = function() {
    try {
        return new XMLHttpRequest();
    } catch ( e ) {}
};
...
xhrSupported = jQuery.ajaxSettings.xhr();
...
support.cors = !!xhrSupported && ( "withCredentials" in xhrSupported );
support.ajax = xhrSupported = !!xhrSupported;

support.ajax is used nowhere in the code and is not documented, XMLHttpRequest object is supported in all modern browsers (including Android 2.3, iOS 6.1, Opera 12 and IE 9 — caniuse.com).
Why not remove xhrSupported variable together with support.ajax and try-catch block?

[gibson042]

Sounds like a great idea; I only see references to it in test/unit/support.js and those can go away as well since we don't guarantee any jQuery.support properties. Would you like to file a PR?

[markelog]

XMLHttpRequest object is supported in all modern browsers

Right, but you can disable it in IE, but i'd say we shouldn't support that anymore.

try..catch was always weird me out here, it's understanble why it was used for activeX but I hear it's pointless.

xhr method was never documented and tested so i'd say we should get rid of it too.

Not sure about support.cors property, we never used it anywhere else, but it might be useful for tests, so i either remove it or add tests for it.

/cc @jaubourg

[FarSeeing]

Not sure about support.cors property, we never used it anywhere else, but it might be useful for tests, so i either remove it or add tests for it.

withCredentials property has appeared only in IE10 (MSDN) so you cannot just drop that check.

[mgol]

@markelog

XMLHttpRequest object is supported in all modern browsers

Right, but you can disable it in IE, but i'd say we shouldn't support that anymore.

I tend to agree, especially on master (I'd like to hear @dmethvin's thoughts on that, though).

Not sure about support.cors property, we never used it anywhere else, but it might be useful for tests, so i either remove it or add tests for it.

IMO we should keep it. Our detection code is not perfect in weird setups so it's nice if people can workaround potential problems just by setting jQuery.support.cors to true (even if we don't officially support it). See e.g. #1881.

[jaubourg]

XMLHttpRequest object is supported in all modern browsers

Right, but you can disable it in IE, but i'd say we shouldn't support that anymore.

I tend to agree, especially on master (I'd like to hear @dmethvin's thoughts on that, though).

Hence the try/catch statement that prevents crashing at startup.

Not sure about support.cors property, we never used it anywhere else, but it might be useful for tests, so i either remove it or add tests for it.

IMO we should keep it. Our detection code is not perfect in weird setups so it's nice if people can workaround potential problems just by setting jQuery.support.cors to true (even if we don't officially support it). See e.g. #1881.

We should definitely keep support.cors, meaning we need to create an xhr at startup, meaning we need the try/catch.

[mgol]

We should definitely keep support.cors, meaning we need to create an xhr at startup, meaning we need the try/catch.

Does IE with native XHR disabled still have the XMLHttpRequest global but it just crashes? Otherwise it'd be better to change the code so that it's a noop or sth like that and not rely on try/catch.

[jaubourg]

(on a side note, we also need to think about those non-browser environments that may not have an xhr implementation into which we may not want to fail miserably)

Does IE with native XHR disabled still have the XMLHttpRequest global but it just crashes? Otherwise it'd be better to change the code so that it's a noop or sth like that and not rely on try/catch.

Whether it's undefined or throws an exception when the constructor is invoked is irrelevant since both cases are handled by the try/catch. It's pretty solid as is which was the point.

[mgol]

(on a side note, we also need to think about those non-browser environments that may not have an xhr implementation into which we may not want to fail miserably)

Right; I'll land #1949 in a moment so that we get covered here.

[mgol]

Whether it's undefined or throws an exception when the constructor is invoked is irrelevant since both cases are handled by the try/catch.

Right but if it never throwed then it'd be better to avoid try/catch. But I guess we don't have the guarantee.

[jaubourg]

But I guess we don't have the guarantee.

Exactly. The module we're talking about being ajax, I tend to apply a "better safe than sorry" policy ;)

[FarSeeing]

Does IE with native XHR disabled still have the XMLHttpRequest global but it just crashes?

I've checked IE11 — you just cannot disable XHR at all. Will check IE9 and IE10 later.

[FarSeeing]

Checked IE9: even when you disable XHR, window.XMLHttpRequest is still available.