What the Heck Does “Script Error” Mean?

Category: error monitoring, JavaScript, joelf, sentry, sponsored

This article was created in partnership with Sentry.io. Thank you for supporting the partners who make SitePoint possible.

If you’ve done any work with the JavaScript onerror event before, you’ve probably come across the following:

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.

The Cause: Cross-origin Scripts

To better understand what’s going on, consider the following example HTML document, hypothetically served from 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 JavaScript 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!

I’m Not a Bad Person, Really!

Despite browsers’ good intentions, there are some really good reasons why you want insight into errors thrown from scripts served from different origins:

Your application JavaScript files are served from a different hostname (e.g., static.sentry.io/app.js).
You are using libraries served from a community CDN, like cdnjs or Google’s Hosted Libraries.
You’re working with a commercial third-party JavaScript library that is only served from external servers.

But don’t worry! Getting insight into a JavaScript error served by these files only requires a few simple tweaks.

The Fix: CORS Attributes & Headers

In order to get visibility into a JavaScript exception thrown by scripts originating from different origins, you must do two things.

1. Add a `crossorigin="anonymous"` script attribute

<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.

Continue reading %What the Heck Does “Script Error” Mean?%

blog