Promise rejection tracking events

[domenic]

Not sure the TAG feels this is in their wheelhouse, but if they do: https://html.spec.whatwg.org/multipage/webappapis.html#unhandled-promise-rejections

[torgo]

@slightlyoff maybe you can comment and we could discuss on Wednesday?

[travisleithead]

[Lightly] discussed on 12/16/2015 telecom. Raw notes: https://pad.w3ctag.org/p/16-12-2015-minutes.md

[torgo]

Taken up at teleconference 16-Dec-2015: https://github.com/w3ctag/meetings/blob/gh-pages/2015/telcons/12-16-agenda.md

[torgo]

@slightlyoff to write up something and attach to this issue with further description.

[torgo]

Agreed to close pending Alex's comments.

[slightlyoff]

This event seems useful and, per discussion, has our support.

@domenic informs me that the other proposal was to extend onerror's event with an additional (occasionally set) value and it seems like this is a fine middle ground.

The IDL looks good and it's great to see it exposed on both windows and workers. Is the specified weak set of unhandled promise rejections exposed to script anywhere? If not, why are its semantics so tightly (un)specified?

Lastly, it's unclear why the spec is explicit about when/where things are reported to developer consoles. It seems out of scope for normative text.

[domenic]

Is the specified weak set of unhandled promise rejections exposed to script anywhere? If not, why are its semantics so tightly (un)specified?

The weak set is a tracking mechanism for what unhandledrejection events have been fired, basically, so that later rejectionhandled events can correspond to them. So the contents are exposed to script, somewhat indirectly. Does that help?

Lastly, it's unclear why the spec is explicit about when/where things are reported to developer consoles. It seems out of scope for normative text.

This was modeled after synchronous errors and the error event, which say:

When the user agent is to report an exception E, the user agent must report the error for the relevant script, with the problematic position (line number and column number) in the resource containing the script, using the global object specified by the script's settings object as the target. If the error is still not handled after this, then the error may be reported to the user.

I think I meant to consistify both of these to say "developer console" per whatwg/html#224 (comment) but I forgot to go back and change the onerror one. I'll do that now.

[dbaron]

One thing I was curious about (and seems to require digging a bit into the ECMA-262) is whether the promise attribute on the event is the last promise in the chain or the promise where the rejection happened (or was last handled). (Is there then a mechanism for developers to inspect that chain to understand what happened?)

Re "developer console" wording; I think there is some value in consistency between implementations in terms of what gets reported to the developer console; I worry about race-to-the-bottom in terms of diagnostics to avoid having clutter for a site developed in a competing browser which then needs to be debugged in another browser (although this is more a fuzzy feeling than something I've properly gamed out in my head).

[domenic]

One thing I was curious about (and seems to require digging a bit into the ECMA-262) is whether the promise attribute on the event is the last promise in the chain or the promise where the rejection happened (or was last handled).

Good question. It's the last promise in the chain, since previous promises in the chain are marked as handled the moment they get chained off of.

[domenic]

Sorry, I missed

(Is there then a mechanism for developers to inspect that chain to understand what happened?)

There is no telemetry-friendly method; you kind of have to hope your error was created with enough information, either in its .stack or its .message. Browser dev tools though certainly can track asynchronous call stacks and promise chains for this sort of thing.