Here's a consistent way to repro it (using mitmproxy):
1. disable window.onerror handler in PolyGerrit (remove catchErrors();)
2. inject throw new Error('boom') after 1 second
3. insert window.onerror that prints arguments using console.log
4. Open https://chromium-review.googlesource.com/?polygerrit=1

Insread of 'boom', receive following:
> ["Script error.", "", 0, 0, null]

mitmdump \
  --replace :~s:catchErrors\\\(\\\):\; \
  --replace :~s:window\.Polymer\ \=\ \{:'window.onerror=function(){console.log(arguments);return true;};window.Polymer = {' \
  --replace :~s:window\.Polymer\ \=\ \{:'setTimeout(_=>{throw new Error("boom")}, 1000);window.Polymer = {'

Tested in Firefox 51.0.1, console output is correct:

> Arguments { 0: "Error: boom", 1: "https://cdn.googlesource.com/polyge…", 2: 14, 3: 90, 4: Error, 2 more… }  gr-app.js:14:32

Bumping to P2 because PolyGerrit team uses this for exceptions reporting and at the moment all exceptions are Script Errors which makes difficult to address them individually.

If there's a workaround, we'll be glad to use it.

I was able to reproduce this issue in latest stable - 56.0.2924.87 , Win 10 with the below code snippet.

window.onerror=function(){console.log(arguments);return true;};window.Polymer
setTimeout(_=>{throw new Error("boom")}, 1000);window.Polymer

["Script error.", "", 0, 0, null]

We will try in older version of chrome and bisect if needed.

Able to reproduce the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.12.2 using chrome version 56.0.2924.87 and canary 58.0.3010.0 as per the steps mentioned in comment #7.

This is non regression issue as the issue seen from M30 old builds.

Thanks,

You noted in the gerrit bug that you tried adding `access-control-allow-origin: *` to the script's response headers. Did you also add `crossorigin=anonymous` to the `<script>` tag? It doesn't look like it's present on https://chromium-review.googlesource.com/?polygerrit=1, but I might be missing something.

Just to recap, here's the full sequence:
- Page is originaly served from gerrit-review.googlesource.com
- It uses <link rel="preload" as="script" for cdn.googlesource.com/../gr-app.js
- It also uses <link rel="import" for cdn.googlesource.com/../gr-app.html
- gr-app.html is an html document (@see Polymer), and loads gr-app.js using script tag.

I've experimented with combinations. Here are some of the cases:

- adding crossorigin="anonymous" to script tag inside gr-app.html alone doesn't solve the problem
- adding crossorigin="anonymous" to preloading import (after as="script") doesn't solve the problem either
- but (Uh! Pen-pineapple..) when both are added, it works!

Thanks for the hint - I'll add that to fix exception reporting.
Not sure if that's the correct behavior though.
Also, let me know if you're interested in headers behavior - I can test that too easily.

Here's the final mitmproxy command that works as expected:

mitmdump \
  --replace :~s:gr-app\.js\"\ as\=\"script\":'gr-app.js" as="script" crossorigin="anonymous"' \
  --replace :~s:script\ src=\"gr-app\.js\":'script src="gr-app.js" crossorigin="anonymous"' \
  --replace :~s:catchErrors\\\(\\\):\; \
  --replace :~s:window\.Polymer\ \=\ \{:'window.onerror=function(){console.log(arguments);return true;};window.Polymer = {' \
  --replace :~s:window\.Polymer\ \=\ \{:'setTimeout(_=>{throw new Error("boom")}, 1000);window.Polymer = {'

Just in case, I've experimented with adding access-control-allow-origin: * to all server responses (including for the script), and it had no effect.

ExecutionContext::ShouldSanitizeScriptError must be returning true. Someone should double-check whether we're doing this correctly (given CORS etc.), given that Firefox apparently behaves differently.

The spec is very unclear on what the actual behavior should be when loading cross-origin scripts without enabling CORS (i.e without using the crossorigin attribute on a script tag). I found multiple places where it mentions that errors can be muted, but it doesn't say exactly when it should be.

I tested on Firefox (53.0, Linux) and they do not obfuscate errors thrown by a cross-origin script, and pass all exception information to an onerror handler. I don't think this was always the case though as this bug (https://bugzilla.mozilla.org/show_bug.cgi?id=363897) indicates. I'm unsure about when they decided to change this, but I think sanitizing the errors for cross-origin scripts by default makes sense and we should keep our current implementation. 

That makes sense, and sounds right when throw new Error and window.onerror are in scripts from different domains.

But when script is loaded from another domain without CORS it appears not to have access to exceptions it had thrown.

So following code will receive sanitized error message:

window.onerror = function() { console.log(arguments); return true };
setTimeout(function() { throw new Error('boom');},1);

Shouldn't the script has access to it's own exception texts?

I think in that scenario, being able to read the original text would be okay. But I don't know if it's possible right now to know in which script an event handler was set.

We can tell where an error event was created (that's part of the spec), which is why I think we use the origin of the error event to determine whether to sanitize the message.