Ben Vinegar
—Script error.
“Script error” is what browsers send to the onerror callback when an error originates from a JavaScript file served from a different origin (different domain, port, or protocol). It’s painful because even though there’s an error occurring, you don’t know what the error is, nor from which code it’s originating. And that’s the whole purpose of window.onerror
– getting insight into uncaught errors in your application.
To better understand what’s going on, consider the following example HTML document, served at http://example.com/test:
<!DOCTYPE html> <html> <head> <title>example.com/test</title> </head> <body> <script src="http://another-domain.com/app.js"></script> <script> window.onerror = function(message, url, line, column, error) { console.log(message, url, line, column, error); }; foo(); // call function declared in app.js </script> </body> </html>
Here’s the contents of http://another-domain.com/app.js. It declares a single function, foo
, whose invocation will always throw a ReferenceError.
// another-domain.com/app.js function foo() { bar(); // ReferenceError: bar is not a function }
When this document is loaded in the browser and JavaScript is executed, the following is output to the console (logged via the window.onerror
callback):
"Script error.", "", 0, 0, undefined
This isn’t a bug – browsers intentionally hide errors originating from script files from different origins for security reasons. It’s to avoid a script unintentionally leaking potentially sensitive information to an onerror callback that it doesn’t control. For this reason, browsers only give window.onerror insight into errors originating from the same domain. All we know is that an error occurred – nothing else!
In order to get visibility into errors thrown from scripts originating from different origins, you must do two things.
<script src="http://another-domain.com/app.js" crossorigin="anonymous"></script>
This tells the browser that the target file should be fetched “anonymously”. This means that no potentially user-identifying information like cookies or HTTP credentials will be transmitted by the browser to the server when requesting this file.
Access-Control-Allow-Origin: *
CORS is short for “Cross Origin Resource Sharing”, and it’s a set of APIs (mostly HTTP headers) that dictate how files ought to be downloaded and served across origins. By setting “Access-Control-Allow-Origin: *”, the server is indicating to browsers that any origin can fetch this file.
By setting the global wildcard, you are indicating that any origin can consume this server. If you want, you can restrict it to only known domains you control, e.g.
Access-Control-Allow-Origin: http://www.example.com, http://www.another-domain.com
Note: Most community CDNs properly set an Access-Control-Allow-Origin header.
Once both of these steps have been made, any errors triggered by this script will report to window.onerror
just like any regular same-domain script. So instead of “Script error”, the onerror example from the beginning will yield:
ReferenceError: bar is not defined", "http://another-domain.com/app.js", 2, 1, [Object Error]
If you’re looking to get a deeper understanding of how JavaScript application monitoring works, take a look at the following articles:
Tasty treats for web developers brought to you by Sentry. Get tips and tricks from Wes Bos and Scott Tolinski.
SEE EPISODESConsidered “not bad” by 4 million developers and more than 100,000 organizations worldwide, Sentry provides code-level observability to many of the world’s best-known companies like Disney, Peloton, Cloudflare, Eventbrite, Slack, Supercell, and Rockstar Games. Each month we process billions of exceptions from the most popular products on the internet.
Here’s a quick look at how Sentry handles your personal information (PII).
×We collect PII about people browsing our website, users of the Sentry service, prospective customers, and people who otherwise interact with us.
What if my PII is included in data sent to Sentry by a Sentry customer (e.g., someone using Sentry to monitor their app)? In this case you have to contact the Sentry customer (e.g., the maker of the app). We do not control the data that is sent to us through the Sentry service for the purposes of application monitoring.
Am I included?We may disclose your PII to the following type of recipients:
You may have the following rights related to your PII:
If you have any questions or concerns about your privacy at Sentry, please email us at compliance@sentry.io.
If you are a California resident, see our Supplemental notice.