Bug Tracker

Opened 7 years ago

Closed 7 years ago

Last modified 5 years ago

#6703 closed bug (wontfix)

getScript() doesn't work for file: in Chrome

Reported by: curiousdannii Owned by:
Priority: low Milestone:
Component: ajax Version: 1.4.2
Keywords: Chrome xmlhttprequest, getscript, ajax Cc:
Blocked by: #7195 Blocking:


Chrome have some bizarre security policy for XHR file: access: http://code.google.com/p/chromium/issues/detail?id=4197 http://code.google.com/p/chromium/issues/detail?id=40787 http://blog.chromium.org/2008/12/security-in-depth-local-web-pages.html

As getScript prefers to use XHR to load scripts when it can, this means it doesn't work for local files in Chrome (fails silently.)

I'll be hardcoding a fix for this in my app, to not use XHR in file:+Chrome. I don't know if there is a smarter way to detect file: support.

Similarly, JSONP will also not work.

Maybe at the same time errors could be raised for ajax methods which must use XHR?

(For a test case, download http://github.com/curiousdannii/parchment/zipball/master and run tests/download_to_array.html. As getScript neither works nor returns an error, the QUnit stops after just two tests.)

Attachments (1)

getScript test.zip (68.2 KB) - added by Larry Battle 7 years ago.
getScript test

Download all attachments as: .zip

Change History (15)

comment:1 Changed 7 years ago by curiousdannii

FYI, I've fixed it like this in my App, though I doubt this is the best possible way: http://github.com/curiousdannii/parchment/commit/49cda7ab30b15147ccf1208f51ac8571597aac78

Changed 7 years ago by Larry Battle

Attachment: getScript test.zip added

getScript test

comment:2 Changed 7 years ago by Larry Battle

Thanks for the fix. I provided a test case.

comment:3 Changed 7 years ago by curiousdannii

It probably fails silently due to #6748.

comment:4 Changed 7 years ago by snover

Keywords: needsreview added
Milestone: 1.4.3
Priority: low

Do we care about file: URLs? Does the rewrite in #7195 already address this?

comment:5 Changed 7 years ago by curiousdannii

Based on the numerous other file: fixes in ajax.js I would say we do care about file: URLs.

I don't think the rewrite will help as it says the script transport is only for cross domain requests.

I'd love to have another way to detect it other than the user agent. But if that's not possible, remember this bug only exists because jQuery uses xhr rather than <script>. Maybe the default could be for <script> to be used (perhaps just for file:, keep xhr for local non-file:?)

Last edited 7 years ago by curiousdannii (previous) (diff)

comment:6 Changed 7 years ago by dmethvin

I totally understand this particular patch satisfies your particular use case, but it makes the behavior of $.ajax even less consistent. Requests based on script tags don't support the same set of features:


A better way to support this would be to provide some way to force use of script tags whether the request was cross-domain or not. That way the caller would understand they were getting a consistent but less-featureful behavior across all platforms.

comment:7 Changed 7 years ago by curiousdannii


Here's how Chrome themselves test for support. I don't know if this is an acceptable test for jQuery.

Well the Chrome policy is that file: is effectively cross-domain. I think they'd like to convince other browsers to follow them, so this may soon need to be generalised.

comment:8 Changed 7 years ago by jvenema@…

This is a change in v6 of Chrome; it's in the top 20 or so requested bugs/fixes for Chrome. Read this discussion for details:


comment:9 in reply to:  6 Changed 7 years ago by anonymous

Replying to dmethvin:

Dave, it would be interesting to see how file: to file: XHR compares with http: to http: XHR as well. You're right that changing to <script> reduces a lot of functionality, but then I don't think that all of that functionality actually works for file: anyway.

We'd probably have to chart it for each browser as file: XHR implementations are less consistent (and for more than just same-origin restrictions!)

comment:10 Changed 7 years ago by curiousdannii <curiousdannii@…>

Sorry that was me. I didn't realise the new Trac would let me post without logging in.

comment:11 Changed 7 years ago by Rick Waldron

Resolution: wontfix
Status: newclosed

See http://bugs.jquery.com/ticket/6703#comment:8 - this has been confirmed.

comment:12 Changed 7 years ago by curiousdannii

Please explain why that is a reason not to fix this bug?

comment:13 Changed 7 years ago by Rick Waldron

Blocked by: 7195 added

comment:14 Changed 6 years ago by dmethvin

Keywords: needsreview removed
Note: See TracTickets for help on using tickets.