Elaborate on Exposed=* advice

[annevk]

Currently we have this:

[Exposed=*] is to be used with care. It is only appropriate when an API does not expose significant new capabilities. If the API might be restricted or disabled in some environments, it is preferred to list the globals explicitly.

I think it would help if we listed the principles or criteria that were used to select the initial set of interfaces. Ideally specific enough that it's clear why ErrorEvent is included and MouseEvent and reportError() are excluded. As that would help a lot with carrying this forward consistently into the future.

(Context: https://github.com/whatwg/html/issues/7591.)

cc @Ms2ger @domenic @smaug---- @leobalter @caridy @mhofman

[caridy]

This one escaped throughout the cracks, it seems! Anyhow, from our perspective (TC39), it doesn't matter much what API are included, the only thing we really care about is that everything is forgeable as specified (configurable and deletable) from the global object. Portability is a no-goal of the ShadowRealm proposal, meaning we know there will be differences between various environments, and that's fine.

As for the Errors, and errors propagation between incubator realm and shadow realm, we will put something together to explain our proposal, trying to make it coherent.

As for the particular question above, my personal opinion is that MouseEvent should not be there because there is no DOM inside the ShadowRealm, nor the concept of a UI, so that one will just simply not work.

[andreubotella]

It seems like so far the set of APIs chosen to be included inside shadow realms has been limited to interfaces (rather than to methods or properties defined in the global property), plus self which is defined programmatically in whatwg/html#5339. In particular, there doesn't seem to be any reason to exclude methods like setTimeout, reportError or even structuredClone, other than the fact that [Exposed=*] as currently defined doesn't work for them.

I don't think such methods have been considered that much, and maybe this is not the right issue (since as mentioned [Exposed=*] wouldn't work with methods), but it is something that should not be left out of consideration just because it would be more difficult to make them work in the specification.

[caridy]

@andreubotella that I don't understand very well, but I certainly expect that methods like setTimeout, structuredClone, etc. to work just fine inside a shadow realm.

[bathos]

@caridy setTimeout, structuredClone, atob etc are operation members of Web IDL global interfaces like Window in HTML. They’re even sensitive to the receiver’s brand and will throw TypeErrors if called with unbranded objects, though a special behavior unique to global interfaces maps undefined to the global platform object of the same [[Realm]] as the function being called so this is not frequently noticed.

Currently there doesn’t seem to be a way for such Web IDL operations to be coherent for a ShadowRealm global object. Has this already been addressed somewhere (assuming these are intended to be included)? It seems like this would need new spec text to become possible, but I didn’t find anything.

[mhofman]

Good call @bathos. When making these functions available on a ShadowRealm's global, we'll need to make sure this global object is acceptable as the receiver, and more importantly, that in the absence of a receiver it's this ShadowRealm's global object being used as fallback receiver and not the principal realm's global object.

[caridy]

@bathos

Currently there doesn’t seem to be a way for such Web IDL operations to be coherent for a ShadowRealm global object. Has this already been addressed somewhere (assuming these are intended to be included)? It seems like this would need new spec text to become possible, but I didn’t find anything.

Ok, I understand now. Few notes thought:

• About the undefined behavior/case, I don't think that should be a problem in practice, maybe the spec side of things are more complicated. At the end of the day, the callable boundary saves us from all those troubles since you can't really grab another global object from within the ShadowRealm.
• If the Web IDL operation installed on a shadow realm can only be invoked with the global object associated to the shadow realm instance, or undefined, the HOST can get the settings object from that by looking at the root realm associated to it.
• As for the various bugs in Chrome (I'm assuming that they are bugs because other browsers do not behave that way) that are using the receiver's brand to construct objects from the realm associated to the receiver, I don't see why those can't be fixed. (e.g.: $0.contentWindow.eval("fetch.apply(top, ['test.js'])") instanceof Promise yields true in chrome, and false everywhere else). In any case, in the ShadowRealm spec we are very clear about this by restricting host APIs to leak objects from another Realm.

[bathos]

As for the various bugs in Chrome (I'm assuming that they are bugs because other browsers do not behave that way)

This sounds like relevant realm behavior. I think you’re correct that Chrome using relevant realm for the returned Promise there is a bug — however using the relevant realm is intended for e.g. the Response object that would settle the Promise (see step 8 of last link). At least, that’s my understanding. I think @domenic is like, the world expert on the relevant/incumbent/entry realm concepts and how they’re expected to be used (or not used) in platform algorithms 😅?

[zcorpan]

Given https://github.com/tc39/proposal-shadowrealm/issues/401 I think we should get rid of Exposed=*.

[domenic]

Given tc39/proposal-shadowrealm#401 I think we should get rid of Exposed=*.

I don't see the connection; can you elaborate? I think https://github.com/tc39/proposal-shadowrealm/issues/401#issuecomment-1971863300 is fair.

[zcorpan]

It seems better to err on the side of exposing to a reviewed set of realms, and by default not expose it to new realms.

[ptomato]

I've tried to create a coherent proposal for this in https://github.com/w3ctag/design-principles/issues/509. (It hasn't had any comments yet from the TAG.) Hopefully this addresses Anne's request in the OP: "I think it would help if we listed the principles or criteria that were used to select the initial set of interfaces." Please let me know what you think.