Also +Mozilla and Microsoft compat folks to get their take on whether it might be worth some collaboration here.

First, thanks to mknichel for such a detailed doc. Some high-level thoughts:

- From an JavaScript/ECMAScript point of view, the biggest thing I notice in the doc that needs standards work is at least getting a little love these days: there's a proposal for structured Error stacks at stage 1 of the TC39 process (https://github.com/tc39/proposal-error-stacks)
- Parts of the doc appear to be out of date (e.g., unhandled Promise rejections are now sent to onerror, at least in Chrome; try/catch does not block deopt in v8 anymore).
- It would be useful if mknichel could point at the biggest pain points, in modern browsers. While I don't think we're ever going to get 100% identical error behavior across browsers (e.g., error messages will always differ), I think there is work we could do here.

FWIW the spec is also a mess here: https://github.com/whatwg/html/issues/958

It's been a low-priority bug of mine to clean that up---low priority because I thought it'd be mostly editorial. If there are significant interop issues here that probably increases the priority for me to dig in and clean up the spec, write tests, and file bugs.

Is this an accurate summary of the interop problems?

- Edge doesn't yet support the fifth parameter to window.onerror
- Cross-origin sanitization is inconsistently implemented (although I know for a fact it's not just Chrome like that document says)
- error events on web workers are inconsistent (I already did a decent amount of spec/test/bug-filing work for this)
- The nonstandard displayName property is still used by some browsers, despite being officially deprecated by ES6's introduction of configurable function names
- Chrome has nonstandard stack-trace capturing APIs
- Stack trace text formats are not interoperable

> unhandled Promise rejections are now sent to onerror, at least in Chrome

This is not accurate; they are sent to window.onunhandledrejection.

Thanks for filing the bug report. 

Domenic - that's a pretty good summary for modern browsers. I would also add:

- Make sure that the URL, line, and column number are correct for every stack frame in every instance". Each browser has a different issue here - Safari and Edge don't support //# sourceUrl for renaming scripts in inline JS and eval'ed JS. Chrome doesn't compute correct line numbers for inlined JS. 

A standardized stack trace format that outlines how the stack trace should look like in all the possible different situations would be great.

As new APIs are introduced, it would also be nice to understand how a global application error handler will handle uncaught errors to ensure that each new API produces reliable data in a way that applications can easily handle. For example, there's no great way to get errors from web + service workers unless you install the error handling code in both the main page and in the service worker script.

I just realized this bug is still sitting around in an unused Blink component.

Domenic, it seems theres a variety of different issues here which should perhaps be tracked in different places (spec issues, missing web-platform-tests, maybe some v8 issues / feature requests, etc.).  Any chance you could go through them and ensure the right issues are filed to at least track the feedback/concerns here in the right places?

I've filed or found the following:

- [TC39 Spec] URL/line/column number computation: https://github.com/tc39/proposal-error-stacks/issues/15

- [TC39 Spec] displayName being used improperly: https://github.com/tc39/proposal-error-stacks/issues/14

- [HTML spec] property figuring out who to attribute an error to: https://github.com/whatwg/html/issues/958

- [HTML spec] figure out how to make cross-origin error muting interoperable: https://github.com/whatwg/html/issues/3149

- [V8] remove nonstandard Error APIs: https://bugs.chromium.org/p/v8/issues/detail?id=6974

- [Edge] lacking 5th argument to onerror: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7203307/

- [Edge] non-interoperable handling of synthetic error events: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/11286304/

- [Blink] onerror return value not handled correctly: https://bugs.chromium.org/p/chromium/issues/detail?id=685276

Shall we close this, and follow up in those issues?

https://bugs.chromium.org/p/chromium/issues/detail?id=578269 is also the tracking bug for V8/Blink to fix the line number for inline JS.

Do you have any bug tracking the standardized stack trace format across all browseres?

Right, I guess I didn't say explicitly. That's https://github.com/tc39/proposal-error-stacks/ in general.

Ah, gotcha. Let me know if you want any input on the proposal for the stack trace. I don't speak spec very well, but I can provide English.

Thanks for doing all of this Domenic.

I think in general it'll be helpful for you to watch that repository and nudge them in the direction of interop. It's often tempting for language-spec-folks to declare things "optional" or "out of scope", which means we then have to do the work of writing a second spec that nails down how the optional/out-of-scope things need to work in the real world.

E.g. https://github.com/tc39/proposal-error-stacks/issues/15 is a bit worrying, and https://github.com/tc39/proposal-error-stacks/issues/12#issuecomment-333354043 makes me think we might indeed need a second spec :(.