107389 2013-01-19 18:14:43 -0800 <script crossorigin> not handled correctly when server doesn't send the right headers 2013-04-02 05:26:08 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Unspecified Unspecified NEW P2 Normal --- 1 bzbarsky webkit-unassigned abarth ap pf rakeshpai syoichi oldest_to_newest 811520 0 bzbarsky 2013-01-19 18:14:43 -0800 Accordiing to https://bugzilla.mozilla.org/show_bug.cgi?id=832587#c0 a <script crossorigin> with a cross-origin URL to a server that's not sending the right access-control-allow-origin headers executes in Chrome. That's not what the spec says to do. In particular, see http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#potentially-cors-enabled-fetch the part about 'If mode is "Anonymous" or "Use Credentials"' under 'If the CORS cross-origin request status is not success'. 814424 1 pf 2013-01-23 11:41:38 -0800 Do you have a testcase that i can look at? Otherwise, if i understand you correctly, this test does what you mean, no? http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/security/script-with-failed-cors-check-fails-to-load.html 814436 2 pf 2013-01-23 11:49:32 -0800 Ah, i see the testcase in the bugzilla bug, looking at it now. 814722 3 pf 2013-01-23 15:12:52 -0800 I wasn't aware that when the parser triggers the script request it follows a different code path that doesn't end up in ScriptElement::notifyFinished() so the check is never done. I'm not super familiar with how the parser does things, is HTMLScriptRunner::executePendingScriptAndDispatchEvent() the right place to do the CORS check (or HTMLScriptRunner::runScript(), or both)?