jQuery Ajax does not allow cross domain in Windows 7 Gadgets

[[email protected]…]

The new ajax module in jQuery does not allow cross domain scripting when running in the Windows 7 gadgets environment. It detects that cross domain scripting is not allowed in the Win 7 gadget environment. Cross domain scripting is allowed in the Win 7 gadget environment. If I hack the jQuery module

jQuery.support.cors = testXHR && ( "withCredentials" in testXHR );

to

jQuery.support.cors = true;

ajax then works in the Win 7 Gadget environment. This of course is not a fix but indicates the source of the issue. Haven't checked but I'm wondering if .HTA apps have the same issue.

[snover]

Thanks for the bug report, but this is not a jQuery bug. Windows 7 Gadgets is not a supported jQuery platform. The transports layer of new ajax is pluggable, so you should just include a custom transport that ignores normal cross-domain support (or uses XDomainRequest).

[jaubourg]

Replying to snover:

Thanks for the bug report, but this is not a jQuery bug. Windows 7 Gadgets is not a supported jQuery platform. The transports layer of new ajax is pluggable, so you should just include a custom transport that ignores normal cross-domain support (or uses XDomainRequest).

Or, more simply, set jQuery.support.cors to true in your script without hacking into jQuery ;)

[anonymous]

I use jQuery mostly for .HTA applications.

Up until version 1.4.4 reading of local XML files was never a problem. Version 1.5 just returns "Unknown".

[jitter]

Replying to anonymous:

I use jQuery mostly for .HTA applications.

Up until version 1.4.4 reading of local XML files was never a problem. Version 1.5 just returns "Unknown".

Umm and how is this comment related to this ticket. I guess you are looking for #8125 which has been fixed in jQuery WIP.

[anonymous]

Sorry, it was just an answer on Mike's "wondering":

"Haven't checked but I'm wondering if .HTA apps have the same issue."

[jaubourg]

So the actual workaround for non supported environment that allow cross-domain while not supporting CORS is to set jQuery.support.cors to true right after jQuery has been loaded. To be added to the doc.

[danheberden]

Also, see #8146 regarding the xhrFields option that will be available 1.5.1

[jaubourg]

#8194 is a duplicate of this ticket.

[jitter]

#8319 is a duplicate of this ticket.

[addyosmani]

Confirming that the docs have been updated to reflect this.

[[email protected]…]

I'm having a related problem, it seems. See my SO question here:

​http://stackoverflow.com/questions/5505802/jquery-ajax-fails-for-unknown-reason

I have set $.support.cors = true, but still am unable to make the ajax request to an HTTPS target. Not sure if this is a $.ajax problem or a Gadget/https platform issue.

[anonymous]

I think CORS being disabled by jQuery when the origin is an html file is loaded from disk into IE (it's not limited to gadgets) is OK, but observed jQuery 1.6.1 behaviour is not: a parameterless GET call to a JSON web service behaves as expected (no request sent, error callback called immediately), but a GET to a normal text/html resource *will* put the request onto the wire, wait for the return packet, and *then* call the error callback with the payload suppressed.