Cryptic "Script Error." reported in Javascript in Chrome and Firefox

Question

The "Script error." happens in Firefox, Safari, and Chrome when an exception violates the browser's same-origin policy - i.e. when the error occurs in a script that's hosted on a domain other than the domain of the current page.

This behavior is intentional, to prevent scripts from leaking information to external domains. For an example of why this is necessary, imagine accidentally visiting evilsite.com, that serves up a page with <script src="yourbank.com/index.html">. (yes, we're pointing that script tag at html, not JS). This will result in a script error, but the error is interesting because it can tell us if you're logged in or not. If you're logged in, the error might be 'Welcome Fred...' is undefined, whereas if you're not it might be 'Please Login ...' is undefined. Something along those lines.

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 could provide a much more targeted phishing page. (This is just one example, of course. But it illustrates why browsers shouldn't allow any data to cross domain boundaries.)

I've tested this in the latest versions of Safari, Chrome, and Firefox - they all do this. IE9 does not - it treats x-origin exceptions the same as same-origin ones. (And Opera doesn't support onerror.)

From the horses mouth: WebKit source that checks origin when passing exceptions to onerror(). And the Firefox source that checks.

UPDATE (10/21/11): The Firefox bug that tracks this issue includes a link to the blog post that inspired this behavior.

UPDATE (12/2/14): You can now enable full cross-domain error reporting on some browsers by specifying a crossorigin attribute on script tags and having the server send the appropriate CORS HTTP response headers.

An update for those that will stumble into this question in the future : broofa is right with the answer and there's no workaround for this.

Obviously other stumbled into this limitation and some bugs requesting for an fix were filed for Firefox : Bug 69301 and for WebKit : Bug 70574

The good news is that the bug has been resolved for Firefox with the release of Firefox 13. This is how you use it :

<script src="http://somremotesite.example/script.js" crossorigin>

crossorigin is equivalent to crossorigin=anonymous and tells the browser to do a CORS fetch of the script without sending credentials.

You must ensure that the script is sent with an Access-Control-Allow-Origin HTTP header value that matches the requesting domain, e.g.,

Access-Control-Allow-Origin: http://myhomesite.example
Access-Control-Allow-Origin: *

otherwise the browser will cancel loading the script.

For Apache:

Header set Access-Control-Allow-Origin "*"

(And see CORS examples for other web servers.)

If you're sending scripts in PHP:

header('Access-Control-Allow-Origin', 'http://myhomesite.example');

I've tested this and it works as expected. all errors from the script.js will be caught by the window.onerror handler with message, file and line details.

The WebKit bug hasn't been fixed yet, but a patch has been proposed (and uses the same solution). Hopefully the fix will be released soon.

More info about CORS here : http://enable-cors.org/

This one took quite a bit to figure out.

We did a bunch of stuff to try and solve it, including doing things like dumping the WHOLE document body back to our servers via Ajax to try and figure it out.

I am still unsure what causes "Script Error." (with the period BTW, that's how it shows up in our Ajax logger) in Firefox, but in Chrome, we were able to narrow it down to...

Drum roll...

The auto translate feature of Google Chrome.

Many English speaking people probably do not even know about this feature, but to test it, I guess visit a non-English site using Chrome. Or better yet, if you dig thru the Chrome options, there's a spot to change the browser language. Change it to something non-English, restart the browser, and visit an English site.

You should get the bar at the top asking if you would like Chrome to translate the page for you.

In our case anyways, the translator was causing the issue since it injects a script tag into your document body and (guessing here) uses some sort of JS-based system to send the content to Google's servers and get them to translate it.

Even though the error in the console was Unreferenced something, the message that was being sent to window.onerror was "Script Error.".

Anyways, there is a cure.

http://googlewebmastercentral.blogspot.com/2007/12/answering-more-popular-picks-meta-tags.html

<meta name="google" content="notranslate"/>

This will do 2 things (as far as we know, maybe more?):

a) Disable the translate bar from popping up in Chrome.

b) Disable translating of the the page via translate.google.com.

In our situation anyways, this solved A TON of these "Script Error." issues we were experiencing.

Excuse the spelling mistakes in this post, I am still on a non-English mode in Chrome writing this, and the spell checker is not set to English ;) Time to switch back.

Enjoy!

Due to the low %, you can assume they're not normal users. Probably users with userscripts, bookmarklets or even maybe just messing with the console on you website. Having the whole HTML of a page where it happens could help testing this theory. As well as the complete error. It should give you a url, is it always the same? Is the line really 0 or just undefined?

I don't think setting default values in you onerror is a good idea and the 0 probably comes from parseInt(ln || 0) when the error isn't really on the page (see examples above).

Adding a if to see if the line is known either in the JavaScript to ignore those errors (because they probably don't come from your own code) or in the server-side code to take care of them separately would, imo, be better.

=== EDIT === Got to: http://www.xavierm02.net/AZE/ Install the user.js file (I did it on Chrome but it should work on Firefox too). Then open the html page on the same browser. It'll show you the error (I only changed that insteal of reporting to the server, it writes it on the page). With 0 as line number.

I had a similar problem: my scripts are served by a subdomain and fall under the same origin restriction. However, I solved this by:

1) adding every script tag like this:

<script type="text/javascript" src="http://subdomain.mydomain.tld" crossorigin="*.mydomain.tld" />

2) modifying the apache httpd.conf by adding the following inside every vhost (you must enbable mod_headers):

<IfModule mod_headers.c>
Header add Access-Control-Allow-Origin "*.mydomain.tld"
</IfModule>

Hope this helps ...

EDIT

On one of my server I was not able to make this functional except by replacing

*.mydomain.tld

by

*

Be aware of the flaws with potentially allowing * to phish extended information. Documentation on CORS, same-origin, img & fonts, cdn is available but very fewer about script tag crossorigin details is available.

In Chrome, I also get "Script error" (on line 0) when loading both the HTML and Javascript from file:// . This doesn't happen in Firefox. Probably overzealous same-origin protection of Chrome.

All is good when loading the same HTML and Javascript over HTTP.

A good article which finally point to this thread. https://danlimerick.wordpress.com/2014/01/18/how-to-catch-javascript-errors-with-window-onerror-even-on-chrome-and-firefox/