Bug Tracker

Ticket #8122 (closed bug: wontfix)

Opened 4 years ago

Last modified 3 years ago

jQuery Ajax does not allow cross domain in Windows 7 Gadgets

Reported by: mike@… Owned by:
Priority: low Milestone: 1.next
Component: ajax Version: 1.5
Keywords: Cc:
Blocking: Blocked by:

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

comment:1 follow-up: ↓ 3 Changed 4 years ago by snover

  • Status changed from new to closed
  • Resolution set to wontfix

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

comment:2 Changed 4 years ago by jitter

  • Priority changed from undecided to low
  • Component changed from unfiled to ajax

comment:3 in reply to: ↑ 1 Changed 4 years ago by 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 ;)

comment:4 follow-up: ↓ 5 Changed 4 years ago by 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".

comment:5 in reply to: ↑ 4 Changed 4 years ago by 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.

comment:6 Changed 4 years ago by 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."

comment:7 Changed 4 years ago by jaubourg

  • 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 4 years ago by jaubourg

  • Keywords needsdocs added; needsdoc removed

comment:9 Changed 4 years ago by danheberden

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

comment:10 Changed 4 years ago by jaubourg

#8194 is a duplicate of this ticket.

comment:11 Changed 4 years ago by jitter

#8319 is a duplicate of this ticket.

comment:12 Changed 4 years ago by addyosmani

  • Keywords needsdocs removed

Confirming that the docs have been updated to reflect this.

comment:13 Changed 4 years ago by aggieben@…

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 4 years ago by 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.

Note: See TracTickets for help on using tickets.