Side navigation
#8122 closed bug (wontfix)
Opened February 01, 2011 01:36PM UTC
Closed February 01, 2011 03:40PM UTC
Last modified March 13, 2012 06:41PM UTC
jQuery Ajax does not allow cross domain in Windows 7 Gadgets
Reported by: | mike@blueonionsoftware.com | 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.
Attachments (0)
Change History (14)
Changed February 01, 2011 03:40PM UTC by comment:1
resolution: | → wontfix |
---|---|
status: | new → closed |
Changed February 01, 2011 09:04PM UTC by comment:2
component: | unfiled → ajax |
---|---|
priority: | undecided → low |
Changed February 01, 2011 09:10PM UTC by comment:3
Replying to [comment:1 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 ;)
Changed February 02, 2011 06:42AM UTC by comment:4
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".
Changed February 02, 2011 12:25PM UTC by comment:5
Replying to [comment:4 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.
Changed February 02, 2011 11:04PM UTC by comment:6
Sorry, it was just an answer on Mike's "wondering":
"Haven't checked but I'm wondering if .HTA apps have the same issue."
Changed February 03, 2011 05:30PM UTC by comment:7
keywords: | → needsdoc |
---|
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.
Changed February 03, 2011 05:30PM UTC by comment:8
keywords: | needsdoc → needsdocs |
---|
Changed February 08, 2011 02:39AM UTC by comment:9
Also, see #8146 regarding the xhrFields option that will be available 1.5.1
Changed February 08, 2011 10:32AM UTC by comment:10
#8194 is a duplicate of this ticket.
Changed February 18, 2011 11:50PM UTC by comment:11
#8319 is a duplicate of this ticket.
Changed February 26, 2011 06:02AM UTC by comment:12
keywords: | needsdocs |
---|
Confirming that the docs have been updated to reflect this.
Changed April 01, 2011 03:04AM UTC by comment:13
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.
Changed June 14, 2011 02:10PM UTC by comment:14
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).