ShadowRealm API

[Ms2ger]

Request for Mozilla Position on an Emerging Web Specification

• Specification title: ShadowRealm API
• Specification or proposal URL (if available): https://tc39.es/proposal-shadowrealm/ + JavaScript ShadowRealm proposal integration  whatwg/html#9893
• Explainer URL (if available): https://github.com/tc39/proposal-shadowrealm/blob/main/explainer.md
• Proposal author(s) (@-mention GitHub accounts): @caridy and @Ms2ger for the HTML integration
• Caniuse.com URL (optional): -
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1566145 + https://bugzilla.mozilla.org/show_bug.cgi?id=1797187
• Mozillians who can provide input (optional): @mgaudet

Other information

[mgaudet]

I have been working on ShadowRealms for a few years now, in the form of implementing it in SpiderMonkey, attempting the web integration, discovering testing concerns, pushing it back to stage 2, supporting its promotion back to Stage 2.7 with the addition of new testing. I would like to highlight that the proposal champions have been very willing to adapt and take on feedback from Mozilla – the dramatically improved situation for testing ShadowRealm as of late as just one example.

My proposed standards position is neutral. The JavaScript implementation of this is not too much work (and has been done for while), however the HTML integration could be costly for the benefit of a relatively small set of stakeholders.

Some concrete concerns:

1. This will require the web platform to maintain a new set of invariants, where incorrectly marking a standard as Exposed=(*) may result in ShadowRealms no longer maintaining the invariants it proposes to. This is a challenge, as it requires institutional maintenance forever; this is a high cost and high costs should be paid only for features which provide a lot of value. I am unconvinced that this is the case for ShadowRealms.

   Now this is not a unique problem to ShadowRealms – similar challenges exist for example in AudioWorklets, but the value proposition of AudioWorklets, where a new capability is brought to the web seems more compelling than ShadowRealms, where less ergonomic but functional workarounds already exist in a number of forms.

2. Delegation to the principal realm / settings object etc. in the HTML PR gives me some pause; the web platform is complicated and I worry that this opens the door to a long period of fixups as it’s discovered in various places that delegation leads to bad results like unintuitive behaviour or perhaps leaking globals from outside ShadowRealms to inside.

I’d also be interested in feedback from @zcorpan and @smaug---- here.

[caridy]

@mgaudet thanks for the feedback. About point 1, keep in mind that the original proposal was just to implement the language intrinsics, and let the user to bring the additional capabilities, back them, implementers, including Mozilla, "asked" for adding host APIs to it, which introduces a significant number of challenges, and our understanding is that the main reason for this request was to avoid the cognitive load for developers to know that there is a separation between the language and the runtime capabilities. What is your recommendation? It sounds like we are going in circles.

[domenic]

I'm not speaking for Mozilla here, but I'll point out that it's a perfectly consistent position for implementers to be negative on a proposal that sticks to just language intrinsics, and then neutral on a proposal that addresses that feedback and adds host APIs.

[ptomato]

I've tried to create a coherent proposal for what should be annotated with Exposed=* in w3ctag/design-principles#509. (It hasn't had any comments yet from the TAG.) I hope that this addresses the problem of maintaining invariants, because authors of specs that add new APIs have clear guidance on whether to use Exposed=* or not. Please let me know what you think.