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.

[markelog]

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).

Then we should document and support it, otherwise we will face more problems in the future. But i wouldn't do that, the only reason i see to leave it in, is for the tests.

Besides, there are way to do that, documented way. Whereas setting jQuery.support.cors is like using ajaxSetup which is not a preferable way, if we say that it's okay, then we're inviting user to change other support properties if he feels like it :-(.

@jaubourg it would be interesting to see in what unsupported envs we would fail, if we would, it would be on the low amount of users, but if we wound't, then we could avoid the "just in case" code.

[dmethvin]

We have too many undocumented edges and I would like to reduce them. jQuery.support is something we've been trying to kill as an external object.

[FarSeeing]

Second thought: why not just remove support.cors?
If the client does not support withCredentials property, but provides some other way to make cross-domain requests (like easyXDM library), it will not have any other way to send request but to force support.cors property. Real life example.

[timmywil]

We'll investigate further for 3.1.0.

[mgol]

jQuery.support.ajax & jQuery.support.cors have been removed in #4347 and will not be defined in jQuery 4.0. The remaining part is the try-catch around jQuery.ajaxSettings.xhr which I'm removing in #4467.