window.onerror
in Firefox and Chrome seems to discard the real error message/location and always pass "Script error.", "", 0
when the offending script is on a different domain than the page itself. I have a site with separate www
and static
subdomains for pages and css/js, which renders error logging rather useless. Is there any way to enable the proper logging of such errors?

- 27,442
- 12
- 81
- 118
-
You should try to disable the same origin policy, guess is because of it that data is striped. for info on how do if you can look at http://stackoverflow.com/q/330427/783219. – Prusse Oct 19 '11 at 19:20
-
@Prusse: I could do that on the browsers used for developement (though there isn't much point to it since I see the errors in my on browser anyway), but the point here is to capture the errors which occur in the visitors' browsers. – Tgr Oct 19 '11 at 20:38
3 Answers
It doesn't sound like there's a workaround for this at the moment (I asked in the Mozilla IRC channel).
I've filed these bug reports to track this issue. Please chime in if you have opinions on what the best solution to this would be:

- 37,461
- 11
- 73
- 73
-
Starting from the bug report, I found [this blogpost](http://jeremiahgrossman.blogspot.com/2006/12/i-know-if-youre-logged-in-anywhere.html) with a good explanation of why these cryptic error messages are necessary for the first place (which always puzzled me before). Thanks for that! – Tgr Oct 23 '11 at 15:38
-
1According to the above bugs this has now been addressed? So the answer to this question is to use the correct CORS headers on your scripts. – Tom Dec 22 '12 at 01:47
The real solution is to use proper try { ... } catch(e) { ... }
blocks in all code. However, I understand that may not always be an option.
If you don't have control over these other scripts, your next best option would be to load them as strings via JSONP, then use eval()
(yes, I know eval is evil) to "inject" them into the current page. This way you'll still get the benefits of using a static domain (no cookies, CDN option, additional concurrent requests, etc), but the JS will end up being on the page's request domain.

- 4,595
- 24
- 20
-
I need control over the script for JSONP too, as I have to turn it into a string and pass it to a callback. `eval`ing can also have small performance drawbacks, such as losing the ability to defer script loading. Try-catch seems to be the strictly better solution, but still somewhat painful for third-party scripts. – Tgr Oct 23 '11 at 14:54