"Script Error" on line 0

Update: Cross-domain error reporting is improving. See this post.

This blog post is to address some confusion about "Script error on line 0" errors as recorded by window.onerror — A confusion I've certainly had, and one that I've seen many others have too.

This Stack Overflow answer does a great job of explaining the details:

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.

Who's affected?

If you are recording errors from window.onerror, and your scripts are loading from a different subdomain or domain, and if such an external file throws an error, the error will be recorded as Script error with no more details, in all browsers except IE. Errors in IE get recorded as expected, irrespective of the hosting domain of the script.

You are not affected if your scripts load from the same domain as your page, or if your errors occur in IE.

Unfortunately, loading scripts from a different domain is a very good idea, and is something you should strongly consider. However, this severely limits the usefulness of window.onerror in non-IE browsers.

Why is this?

It's because of a possible exploit in browsers that support window.onerror. Firefox fixed this issue by restricting the information available in window.onerror for x-domain scripts. As far as I can tell, WebKit and Opera (which were late entrants in the window.onerror game) have had this behavior from the outset. In IE, even as recently as IE9, this security vulnerability still exists.

What about Errorception?

From the very beginning, Errorception has not recorded any Script error errors, because the information is insufficient to debug in any sensible way. However, I never knew the cause of this error, and admittedly have been confused about how it originated. Now that it's clear why this error occurs, it's also clear that there's a class of errors that Errorception cannot catch (hat-tip: @vitaly_babiy), and that it's necessary to come up with an alternative mechanism to catch such errors. All isn't lost yet — IE still gives enough information to debug the error in all cases, and all this only happens if you loading from across domains. However we clearly need to do better than window.onerror.

Lest you think otherwise, problems like this are in fact the very reason you should use services like Errorception. Catching and processing errors is evidently a complex task, and is something you don't want to bother with too much — you just care about the results. Errorception takes on the responsibility to catch errors for you, and to process them to make them easy to digest. Setbacks like this are common, and we've always found a way around such problems.

Why I'm telling you all this is because I think it's far better to educate people and be open about Errorception's limitations, than to hide such information. Hiding information is tantamount to lying, and I don't want to do that.

I'll be actively looking for alternative ways to record errors, since window.onerror has these (and other) restrictions. I already have a couple of ideas to improve error information, and will be testing them out soon. Meanwhile, I'm open to suggestions, if any.