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)
Change History (14)
Changed June 22, 2010 04:51AM UTC by comment:1
Changed July 18, 2010 10:50PM UTC by comment:2
Thanks for the fix. I provided a test case.
Changed October 15, 2010 12:20AM UTC by comment:4
| keywords: | Chrome, xmlhttprequest, getscript, ajax → Chrome, 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 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 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 comment:7
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 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:
Changed October 21, 2010 09:07AM UTC by 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 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 comment:11
| resolution: | → wontfix |
|---|---|
| status: | new → closed |
See http://bugs.jquery.com/ticket/6703#comment:8 - this has been confirmed.
Changed October 23, 2010 01:04AM UTC by comment:12
Please explain why that is a reason not to fix this bug?
Changed October 23, 2010 02:22PM UTC by comment:13
| blockedby: | → 7195 |
|---|
Changed November 02, 2010 03:26AM UTC by comment:14
| keywords: | Chrome, xmlhttprequest, getscript, ajax, needsreview → Chrome xmlhttprequest, getscript, ajax |
|---|
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