Skip to main content

Bug Tracker

Side navigation

#6703 closed bug (wontfix)

Opened June 22, 2010 04:02AM UTC

Closed October 22, 2010 10:26PM UTC

Last modified March 13, 2012 10:34PM UTC

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: Blocking:
Description

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 July 18, 2010 10:49PM UTC.

    getScript test

Change History (14)

Changed June 22, 2010 04:51AM UTC by curiousdannii comment:1

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 July 18, 2010 10:50PM UTC by Larry Battle comment:2

Thanks for the fix. I provided a test case.

Changed August 16, 2010 04:27AM UTC by curiousdannii comment:3

It probably fails silently due to #6748.

Changed October 15, 2010 12:20AM UTC by snover comment:4

keywords: Chrome, xmlhttprequest, getscript, ajaxChrome, xmlhttprequest, getscript, ajax, needsreview
milestone: 1.4.3
priority: → low

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

Changed October 15, 2010 01:14AM UTC by curiousdannii comment:5

_comment0: Based on the numerous other file: fixes in ajax.js I would say we do care about file: URLs. \ \ I would say the rewrite doesn't 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:?)1287105660126254

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:?)

Changed October 15, 2010 02:16AM UTC by dmethvin comment:6

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:

https://spreadsheets.google.com/ccc?key=0Aj5JJFjq9rZDdC1OQjJOcmtjTmtBUVdXV2NPczE2R2c&hl=en#gid=0

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.

Changed October 15, 2010 03:00AM UTC by curiousdannii comment:7

http://codesearch.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/chrome/common/extensions/docs/js/bootstrap.js

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.

Changed October 19, 2010 03:45PM UTC by jvenema@gmail.com comment:8

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:

http://code.google.com/p/chromium/issues/detail?id=47416&sort=-stars&colspec=ID%20Stars%20Pri%20Area%20Feature%20Type%20Status%20Summary%20Modified%20Owner%20Mstone%20OS

Changed October 21, 2010 09:07AM UTC by anonymous comment:9

Replying to [comment:6 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!)

Changed October 21, 2010 09:12AM UTC by curiousdannii <curiousdannii@gmail.com> comment:10

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

Changed October 22, 2010 10:26PM UTC by rwaldron comment:11

resolution: → wontfix
status: newclosed

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

Changed October 23, 2010 01:04AM UTC by curiousdannii comment:12

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

Changed October 23, 2010 02:22PM UTC by rwaldron comment:13

blockedby: → 7195

Changed November 02, 2010 03:26AM UTC by dmethvin comment:14

keywords: Chrome, xmlhttprequest, getscript, ajax, needsreviewChrome xmlhttprequest, getscript, ajax