Simplify XHR detection

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?

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?

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

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

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.

Ajax: simplify XHR detection.

@markelog

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

@dmethvin

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.

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.

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

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

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.

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

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.

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

@jaubourg

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.

Ajax: Simplify jQuery.ajaxSettings.xhr

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.

Ajax: Simplify jQuery.ajaxSettings.xhr

Navigation Menu

Repository navigation

Simplify XHR detection #1967

8 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Simplify XHR detection #1967

Description

Activity

gibson042 commented on Dec 24, 2014

markelog commented on Dec 24, 2014

FarSeeing commented on Dec 26, 2014

mgol commented on Dec 26, 2014

jaubourg commented on Dec 26, 2014

mgol commented on Dec 26, 2014

jaubourg commented on Dec 26, 2014

mgol commented on Dec 26, 2014

mgol commented on Dec 26, 2014

jaubourg commented on Dec 26, 2014

FarSeeing commented on Dec 26, 2014

FarSeeing commented on Dec 26, 2014

markelog commented on Dec 26, 2014

8 remaining items

mgol commented on Aug 21, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions