SES error censorship issues

[naugtur]

Describe the bug

In some circumstances I've seen SES error censorship produce an error with a falsy value as message and a stack containing only references to SES concole implementation. Other times it corrupts the error message.

All examples I found to date seem related to errorTrapping implementation

I'll collect ways to reproduce it in this issue.

1. broken functionality

1.1. when opening a html file via file:// protocol with invalid syntax in a script, error gets censored to nothing. errorTrapping: "none" prevents the issue.

test1.tar.gz

1.2. When a multiline message is thrown in Node.js, SES will print all lines of the message, except first, twice. (does not happen in the browser) test2.tar.gz

2. bad UX

2.1. The Error("",{ cause: e }) output can be considered correct, but differs between errorTrapping default, errorTrapping: "none" and no lockdown at all.

test3.tar.gz

2.2. console output of unhandled rejections is not compatible with browsers

async function que() {
  throw Error('karramba')
}
que()

2.2.1. FireFox: the original uncaught error in promise is reported first, the SES version after a few seconds

2.2.2. Both FireFox and Chromium: 3 console lines each are an error with a misleading stacktrace.

[erights]

Some info on "1. broken functionality". All examples are from Brave unless stated otherwise.

which is from https://github.com/endojs/endo/blob/f8aa142fb0fd70c366296e168097ff4d819db1e5/packages/ses/src/error/tame-console.js#L159

As seen in the hover, event.error is null, which I think is why no error is reported. with errorTrapping: none, the browser reports the error directly to the browser console, bypassing the causal console.

This does not say "SyntaxError" or any other particular kind of error. But it does report the actual problem along with the source file and line number it occurs on.

[erights]

The full event is

in which the ErrorEvent's message is the less informative 'Script error.' and there is no filename or linenumber.

[erights]

An relevant irony buried in https://github.com/endojs/endo/blob/f8aa142fb0fd70c366296e168097ff4d819db1e5/packages/ses/src/error/tame-console.js#L149-L165 is that (in this browser case) errorTrapping: 'none' doesn't mean none, it means use the platform's default trapping behavior, whereas errorTrapping: 'platform' doesn't mean platform, it means attempt to emulate the platform's default trapping behavior by other means.

That's why we're seeing the platform's trap report with errorTrapping: 'none' but we're seeing our imperfect emulation with errorTrapping: 'platform'. The misleading naming is a SES bug. But the imperfection is not. Given that the platform's support of user trapping does not provide any error, our emulation must stay flawed.