Add HostPromiseRejectionTracker

[domenic]

This is a non-observable change that will allow HTML to provide events for tracking promise rejections, as outlined in https://github.com/domenic/unhandled-rejections-browser-spec.

On top of #75 for convenience.

[benjamingr]

👏👏 Great to see this finally progress.

[bterlson]

I am bought off on the necessity of some affordance for Promise rejection tracking for dev tools. What I don't yet understand are the following:

1. What are the compelling scenarios for making this a user-facing API?
2. What are the security constraints in doing so? I imagine there are similar constraints to onerror where the origin of scripts throwing the error have to be considered. Possible to enumerate these for those of us less familiar with HTML-land (me :-D).
3. Why is this being done in a host-dependent way? Would it be better to pursue a solution that fits entirely in 262 so all JS environments can benefit from this machinery?

These aside, this could be contentious so I think we should discuss this in November at the F2F before I pull it in. I want be careful not to compromise our consensus process by overzealously merging PRs.

[domenic]

Sure, happy to help!

What are the compelling scenarios for making this a user-facing API?

This was outlined in the original proposal, which maybe I should have included in the commit message. Essentially, the use case is the same as for window.onerror: telemetry.

What are the security constraints in doing so? I imagine there are similar constraints to onerror where the origin of scripts throwing the error have to be considered. Possible to enumerate these for those of us less familiar with HTML-land (me :-D).

Yeah, exactly; it's origin-related. Actually, thank you for the reminder; I had not taken care of that properly in whatwg/html#224 yet. But yes, you should not be able to read error messages or stack traces from cross-origin scripts. This is taken care of by the "muted errors" flag, which you can click to see all the places it impacts.

Why is this being done in a host-dependent way? Would it be better to pursue a solution that fits entirely in 262 so all JS environments can benefit from this machinery?

Error reporting mechanisms vary greatly across hosts. Web browsers have multiple global scope types, each with their own type of event loop and resulting way of enqueuing tasks to notify as such. There you use onunhandledrejection and addEventListener("unhandledrejection", ...) in conformance with existing platform conventions, and to allow easy adaptation by libraries that are already using window.onerror. In contrast, Node.js has two separate "microtask-esque" queues, their nextTick queue and the V8 microtask queue, which interact with the timing of this event. And it uses the process.on("unhandledRejection", ...) mechanism, which is conceptually similar to browser EventTargets but different in many specifics, up to and including the conventional casing of the event name used.

Although in theory providing such machinery in 262 would be nice, in that it would allow writing portable code for this sort of thing, in practice doing so would be both difficult and have a low payoff. It would be difficult in that it would require creating new machinery for this type of event handling or live list or similar, and driving that to consensus. And it would require specifying the event loop at a much deeper level than ES currently does; as you can see from e.g. https://github.com/whatwg/html/pull/224/files or https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981, the level of detail needed for a feature like this is pretty great, and that's not even trying to be compatible with environments outside browsers. Finally, it would not be that useful either, since error-reporting mechanisms are not really something you want portable code for. Reporting client-side errors in a browser-based web app is going to be done very differently than logging server errors in a Node.js server, or logging runtime errors in an embedded device. All of the telemetry uses are going to require some kind of I/O, so the code isn't going to be all that portable anyway.

These aside, this could be contentious so I think we should discuss this in November at the F2F before I pull it in. I want be careful not to compromise our consensus process by overzealously merging PRs.

Seems quite reasonable to me. Feel free to tag this with "pending f2f" or something. I'll put the topic on the agenda.

[bterlson]

Per Nov 18 TC39 meeting, this is good to go. Additionally, TC39 has empowered the editor to allow changes to improve the layering of ECMAScript with other relevant specifications when the semantics are unobservable. Only requirement is that they are called out explicitly in the release notes. 🎆

[benjamingr]

👏🏻 awesome

[bterlson]

@domenic can you rebase?

[anba]

[[PromiseIsHandled]] needs to be added to the list of internal slots in 25.4.3.1 Promise, step 3.

[domenic]

Rebased and fixed @anba's find. Not sure what prefix to use besides "Normative" or "Editorial" since this is kind of a third category... will leave that to @bterlson.

[bterlson]

Committed as e89e31d.