Web Performance Monitoring
Script Error: What is it and how to solve it
A generic "Script error." is what the page receives when an uncaught JavaScript error occurs in a file served from a different origin.
DevTools usually still shows the real message, file, and line. What gets hidden is the detail passed to window.onerror: the message becomes Script error., the filename is empty, and the line and column are 0. An error tracker that listens for that event only sees those values.
Why the Script error occurs
The browser hides those details from the page when the script that threw is served from a different origin than the page. A subdomain counts as a different origin.
The same-origin policy is what stops a page from reading another site's responses. An error object is the same kind of leak: the message might include data from that other origin. The page's error handler receives Script error. unless the script was loaded in a way that opts in, and the server agrees.
How to solve the Script error
You need two changes, and the order matters. Set the CORS header on the host that serves the script first. Then add the crossorigin attribute on the page.
If you add the attribute before that header is in place, the browser does not hide the error. It blocks the script. The CORS check fails and the file never runs. The header on its own still leaves you with Script error.: the browser loads the file, and it still hides the exception.
Step 1. Set the CORS header
On the server that hosts the JavaScript file, allow the page's origin to read the response:
Access-Control-Allow-Origin: *
* allows any origin. If the file should only load on your site, send that origin instead:
Access-Control-Allow-Origin: https://example.com
When the value is a specific origin rather than *, also send Vary: Origin. A CDN that caches the file otherwise can store one site's response and serve it to a different site.
If the script tag will use crossorigin="use-credentials", so the request includes cookies, * is not valid. Send the page's exact origin, and also:
Access-Control-Allow-Credentials: true
Step 2. Add the crossorigin attribute
After the header is live, add crossorigin to the script tag that loads the file:
<script crossorigin="anonymous" src="https://cdn.example.com/script.js"></script>
anonymous sends the request without cookies. Use use-credentials only when you also set Access-Control-Allow-Credentials: true, as in the previous step.
Where Cronitor shows it
Once the snippet from the RUM quickstart is on the page, JavaScript errors land on the site's Errors tab. The tiles are Sessions, Errors, Errors per Session, and Sessions with Errors. The Error Inbox lists the type, the message, and the file, with first seen, last seen, and occurrences.
A cross-origin failure that window.onerror has redacted shows up as Script error. with an empty filename. After the attribute and the header are both in place, the inbox gets the real type and the file.
Errors tab. The inbox is every reported script error, redacted or not.
More on the product side is in real user monitoring and the RUM docs.
Conclusion
Script error. is what window.onerror reports for a cross-origin exception. With Access-Control-Allow-Origin on the file and crossorigin on the script tag, the message, file, and line number come through to the page's error handler and to Cronitor's error inbox.