When a script that isn't served from the same origin as the document throws an error, then the error message exposed to window.onerror is "Script error." and the stack trace is empty.

This is to spec and it can be worked around by
- serving the script with CORS headers
- requesting the script as CORS.

While the behavior is understandable, it leads to bad developer experience in practice and is overzealous with respect to the threat model.

My understanding of the threat model is that it is worried about attackers circumventing CORS restrictions by e.g. script srcing a privileged file from a cross origin and then gaining insights from the error message that happens because the file is not valid JavaScript.

I think Chrome could successfully prevent the threat while maintaining most of the developer experience:

- The "Script error." rewriting should be limited to initial execution of a script, because all other stack entry points can be wrapped in try-catch and hence aren't subject to the limitation anyway.
- Potentially the rewriting of the error message could be limited to SyntaxError only.

Since SyntaxErrors are essentially irrelevant in JavaScript production monitoring, these changes would reinstate the ideal developer experience while maintaining the desired protection against data leaks.

As an additional data point: Safari implements the same behavior as Chrome, but Edge doesn't handle cross origin error specifically at all.