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

[curiousdannii]

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

[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

[Larry Battle]

getScript test

[Larry Battle]

Thanks for the fix. I provided a test case.

[curiousdannii]

It probably fails silently due to #6748.

[snover]

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

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

[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:

 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.

[curiousdannii]

 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.

[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:

 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

[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!)

[curiousdannii <curiousdannii@…>]

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

[rwaldron]

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

[curiousdannii]

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