Consider not exposing ErrorEvent/PromiseRejectionEvent in ShadowRealms

[smaug----]

Exposing PromiseRejectionEvent in Shadow Realms doesn't make much sense, since the global isn't an EventTarget.
https://html.spec.whatwg.org/#unhandled-promise-rejections just doesn't work with that kind of globals.
And https://html.spec.whatwg.org/#report-the-exception doesn't really work either, again because the global isn't an EventTarget.

[annevk]

@domenic @Ms2ger @leobalter do you agree with @smaug---- about #7244?

[domenic]

I'm not sure.

I think it would generally be useful to expose ErrorEvent, so that people could fire ErrorEvents at their own custom EventTarget instances, in case application-specific errors occur. That seems nicer for developers than forcing them to use CustomEvent or Event-with-expandos for such cases.

Directing promise rejections to custom EventTarget instances seems less likely to be useful, but not inconceivable. And I kind of feel like we should treat sync errors and promise rejections the same.

So I lean toward including it, even though the browser will never fire it.

But another consistent perspective would be to keep the number of Event subclasses exposed minimal, e.g. only Event and CustomEvent.

[leobalter]

I was able to review this internally with my team and we all agreed @domenic's feedback feels pretty solid. Please let me know if there is anything else I can provide from my end.

[smaug----]

I could vaguely see someone using ErrorEvent for something, but PromiseRejectionEvent rather unlikely.
In general the logic seems to be that one might use something for something, so expose. And in that case exposing for example MouseEvent sounds reasonable. One could use MouseEvent to emulate some UI actions.
But events aren't exposed that way in workers either.

[caridy]

We discussed this topic today during the SES meeting, and we are in agreement with @domenic's position as well.

@smaug---- with respect to PromiseRejectionEvent, there are other things that the host can do in the future to provide similar mechanism to what you get via window today, it might be placed into another value, not the global object. @mhofman suggested that maybe something like globalThis.errors, which could be an event target just for that purpose. Exposing the PromiseRejectionEvent will be a step closer to eventually provide such mechanism.

[mhofman]

I also want to re-iterate that no matter what, the incubator realm (or whatever the name is for the realm which holds the window as global), is not allowed to expose the error or promise objects from shadow realms, as that would violate the callable boundary.

[smaug----]

@caridy, I can totally understand exposing PromiseRejectionEvent once there is some API using it. But before that? We don't normally expose interfaces beforehand just in case some API later might use them.

[caitp]

Has there been agreement about continuing to expose PromiseRejectionEvent and ErrorEvent?