Table of Contents
This behavior is intentional. It prevent scripts from leaking information to external domains. For an example, imagine that you accidentally visited a site called evilsite.com that serves a script pointing to your bank's home page such as "mybank.com/index.html".
If evilsite.com does this for the top 20 or so bank institutions, they'd have a pretty good idea of which banking sites you visit, and enables it to target you with a superior phishing page. This is one such example as to why browsers shouldn't allow any data leak across domains.
The browser is trying to hide the original error source and everything related to it. Surfacing anything meaningful would go against the very purpose of issuing the "Script error." message. See Webkit source that checks for origin (Chrome/Safari) and Firefox source that handle this error.
Enabling CORS on the server and client side fixes the issue in Chromium, Chrome and Firefox as of October 2014. No such on Safari :(.
http://enable-cors.org/ has listed the steps to enable CORS on both client and server side in a simple manner. I will list the same for you.
You can also whitelist domains instead of allowing every site with "*". As per Access-Control-Allow-Origin header W3 spec, the value should either be a single origin or the string "null" or "*".
Set the crossorigin attribute in the script tag to anonymous.
See CORS Settings attributes W3 spec for more details on the crossorigin attribute and all the values it can take. It is important to note that this attribute has no effect on browsers that don't support CORS, see CanIUseCors to check which browsers support it. Also, some browsers like Chrome expect the Access-Control-Allow-Origin to be set in the response header when it sees the crossorigin attribute on the script tag. If this header is missing , it will refuse to the load the script.
- no-cors.js that has no Access-Control-Allow-Origin header in it's response
- cors.js that has Access-Control-Allow-Origin header in it's response
I have modified the window.onerror function that is described in detail at MDN - window.onerror to showcase the error message, error stack, file and line number on the webpage. The two examples shown below are iframed urls pointing to http://ravikiranj.net/hacks/cors-demo/no-cors.html and http://ravikiranj.net/hacks/cors-demo/cors.html respectively.
As you can see from the above, Enabling CORS on both the server and the client side has indeed fixed the issue. To make sure that you are indeed serving the header, you can use Chrome's Network tab to inspect them as below.