#8122 closed bug (wontfix)
jQuery Ajax does not allow cross domain in Windows 7 Gadgets
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | low | Milestone: | 1.next |
Component: | ajax | Version: | 1.5 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
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.
Change History (14)
comment:1 follow-up: 3 Changed 12 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 Changed 12 years ago by
Component: | unfiled → ajax |
---|---|
Priority: | undecided → low |
comment:3 Changed 12 years ago by
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 ;)
comment:4 follow-up: 5 Changed 12 years ago by
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".
comment:5 Changed 12 years ago by
comment:6 Changed 12 years ago by
Sorry, it was just an answer on Mike's "wondering":
"Haven't checked but I'm wondering if .HTA apps have the same issue."
comment:7 Changed 12 years ago by
Keywords: | needsdoc added |
---|
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.
comment:8 Changed 12 years ago by
Keywords: | needsdocs added; needsdoc removed |
---|
comment:9 Changed 12 years ago by
Also, see #8146 regarding the xhrFields option that will be available 1.5.1
comment:12 Changed 12 years ago by
Keywords: | needsdocs removed |
---|
Confirming that the docs have been updated to reflect this.
comment:13 Changed 12 years ago by
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.
comment:14 Changed 12 years ago by
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.
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).