Isolated worlds (was Re: Module isolation)

Kevin Curtis kevinc1846 at
Mon Jan 11 23:12:34 PST 2010


The 'isolated world' concept looks very interesting. But how is an "isolated
world" accessed - is there an ES api:

evalCodeInIsolatedWorld("... ES source code ...");

Is there an web page you can point me to?

Isolated worlds point to the same underlying native DOM objects - so that
DOM changes made in isolated world 'A' will be visible in isolated world 'B'
- even if the DOM wrappers have been tweaked in 'B'. Is there a way to only
make part of the native DOM tree accessible to a isolated world?


On Mon, Jan 11, 2010 at 6:49 AM, Adam Barth <abarth-mozilla at>wrote:

> [Re-sending now that I've subscribed with this address]
> I haven't been following this module discussion very closely, but
> these recent comments sound related to something we've been playing
> around with in WebKit.  We have a mechanism (called an "isolated
> world") that lets multiple JavaScript contexts share access to the
> same DOM without ever exchanging JavaScript pointers with each other.
> Essentially:
> 1) Each world gets it's own global object, complete with independent,
> mutable built-in objects.
> 2) Each world gets it's own set of (mutable) DOM wrappers.
> For those not familiar with the details of browser implementations,
> JavaScript DOM objects are usually implemented as wrapper objects
> around the "native" object, implemented in C++.  Because each isolated
> world gets its own wrappers, the usual one-to-one relation between the
> native objects and it's wrapper is replaced with a one-to-many
> relation.
> This trick works nicely because DOM is a language-neutral interface.
> Just like you can have Python and JavaScript bindings for the DOM,
> isolated worlds essentially lets you have JavaScriptA and JavaScriptB
> bindings.  The key invariant is that two worlds never exchange
> JavaScript pointers (which you can think of as object-capabilities, if
> you like), just like Python and JavaScript would never exchange
> pointers if they interacted with the same DOM objects.
> I'm not sure this mechanism is directly applicable to future versions
> of ECMAScript because we're able to implement it just fine using ES5.
> However, it might be an approach worth considering in designing a
> module system for ECMAScript.
> Adam
> On Sun, Jan 10, 2010 at 9:38 PM, Brendan Eich <brendan at> wrote:
> > On Jan 10, 2010, at 9:30 PM, David-Sarah Hopwood wrote:
> >
> >> Brendan Eich wrote:
> >>>
> >>> On Jan 10, 2010, at 1:14 AM, Kevin Curtis wrote:
> >>>
> >>>> From SecureEcmaScript proposal:
> >>>> 6. The top level binding of this in an evaled Program is not the
> >>>> global object, but rather a frozen root object containing just the
> >>>> globals defined in the ES5 spec.
> >>>
> >>> For many current applications, the frozen |this| object is not
> necessary
> >>> or desirable in global code. The essential characteristic of modules,
> >>> isolation for each module's "inside" from unimported effects of other
> >>> modules, does not necessarily mean no mutation of primordial objects.
> >>
> >> On the contrary, it does necessarily mean that. If you can mutate
> >> primordial objects, then there is no isolation of any module. There
> >> may be a reduction in the possibilities for accidental interference
> >> between modules, but that should be distinguished from isolation.
> >
> > Who said primordial objects are shared between modules? You assume too
> much
> > in assuming your favored conclusion.
> >
> > There are three things a module has to deal with to interact with JS in
> > browsers:
> >
> > 1. The global object and its Object, Date, etc. primordials.
> > 2. The |this| binding for "global" code in the module, at the module's
> top
> > level.
> > 3. The scope chain tail object, the only object on the scope chain for
> > global code in ES1-5.
> >
> > These are not necessarily the same at all. The lexical_scope proposal
> > eliminates 3 by making the top-level a lexical environment, not an
> object.
> > The |this| binding may or may not refer to the global object. And it's
> not
> > settled whether, in browsers with many global objects (one per
> > window/frame/iframe) there is only one global among N>1 modules, or a
> global
> > per module.
> >
> > If modules do not use free variables, only what they import, then you're
> > wrong that isolation requires freezing. Modules could use their own
> > primordials, or none (only library code, possibly better versions of
> Date,
> > etc.). The object and array initialisers and regexp literals would have
> to
> > construct using some "original value" of Object, Array, RegExp. But not
> > necessarily a frozen one, if per-module.
> >
> > That you conflate frozen primordials with isolation is exactly the kind
> of
> > over-specification through shortest-path evolution of ES5 to which I
> object.
> > It is not going to fly in TC39 among all the browser vendors. We need to
> > hear from Apple, Microsoft, and Opera, but I'm already objecting to this
> > kind of axiom planting. Let's back up and talk about modules from
> premises
> > forward.
> >
> > /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list