Last Comment Bug 832587 - Scripts do not get evaluated if the script tag uses the crossorigin attribute and the server doesn't send a access-control header
: Scripts do not get evaluated if the script tag uses the crossorigin attribute...
Status: RESOLVED INVALID
:
Product: Core
Classification: Components
Component: Security (show other bugs)
: 17 Branch
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-18 22:45 PST by Rakesh Pai
Modified: 2013-01-19 18:12 PST (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Rakesh Pai 2013-01-18 22:45:00 PST
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17

Steps to reproduce:

Code here: https://gist.github.com/4571053

The HTML page references an external script tag with a cross-origin attribute. The external script sets a global variable. The markup also has another inline script to alert the value of the global variable. The expectation is that the inline alert will reflect the value of the global variable set in the external script.


Actual results:

Behavior depends on whether the external script was sent with "Access-Control-Allow-Origin" header or not. If the header is not set, the inline script throws a ReferenceError. This seems to indicate that the script wasn't loaded. This can be verified by using Firebug later to check if there's a "foo" variable in global scope, and there isn't. (The script does get downloaded, as can be verified from the "Net" tab in Firebug.)

However, the script loads perfectly fine when the access control header is set.

Behaviour verified in Firefox 17 and 18.


Expected results:

Ideally, the presence or absence of the access-control header shouldn't affect script evaluation. I'm not sure if this behaviour in Firefox is intentional.

I've verified that Google Chrome behaves as one would expect, where the presence (or absence) of the header doesn't affect script evaluation.

AFAICT, this isn't a problem for production websites, but it makes dev workflows harder since now developers should either not use crossorigin attributes at dev time, or should use crossorigin attributes and ensure that the server sends the access-control header to go with it.
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2013-01-19 18:07:30 PST
The behavior is intentional, and quite clearly required by the CORS spec.  A CORS load that doesn't see the right headers is treated as a network error for the resource.

If Chrome isn't doing that, please do file a bug on them.  I do know their CORS implementation gets this wrong in many other cases.
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2013-01-19 18:12:03 PST
I filed https://bugs.webkit.org/show_bug.cgi?id=107389 so no need to do that.

Note You need to log in before you can comment on or make changes to this bug.