Windows/global objects have three key pieces to them in the browser: the global object, implicit references to the global object via the global scope, and explicit references to the global object via "window" and "this".

These are all interrelated and the differences are subtle. In fact, I probably don't have this completely right, but in an effort to provide something to work from ...

The global object is what the HTML5 spec calls the "browsing context". It's what contains the document. It's the object that has the "document" member which points to the document object.

 It's tempting to call this the window, but this is confused by the fact that the "window" member of the global object is actually a different object, what the HTML5 spec calls a WindowProxy. The big deal with the the proxy is that navigation, e.g., window.location = ..., changes the proxy but leaves the browsing context intact (activation issues notwithstanding). For example, if you create a window, get a reference to the document within the window, then change the window location and grab a reference to that document, you have two completely valid references to two documents.

There is another, implicit way to access the global object, and that's via the global scope, e.g., "document", as opposed to "window.document". Changing window location does not change that. So in the example above, for one of those contexts, window.document !== document.

There's not supposed to be any way to get an explicit reference to the global scope, just like you can't get an explicit reference to the scope created by a closure. What this means is that anything that returns a reference to the global object actually returns a reference to the WindowProxy. For example, (function(){return this;}()) returns a reference to the proxy, not to the global object.

To do this right, you need to make global "this" return a reference to the proxy. I don't know how many JS interpreters can handle this, or expose this in a way env.js can use. SpiderMonkey has a specific built-in type for just this purpose (and it's what FireFox uses). SpiderMonkey calls these objects split objects. The proxy is called the outer object and the real global object, the one that should be set as the global scope of any JavaScript executed that context, is called the inner object. SpiderMonkey goes out of it's way to make sure that you never use the outer object as a scope and that any time you would create an explicit reference to the inner object, you instead return a reference to the outer object.

So the idea would be that when we create a new window, we create the new global object and create a proxy for it. We return the proxy to the object that created the window, and we set the global object as the scope for the code that actually gets loaded to the global itself. If possible, we make "this" return the proxy.

Every browsing context should (in the pure sense) be completely independent except for browser-specific things, like the window reference. In particular, the global objects like Object and Array, and in theory, even the DOM classes should be independent.

I'm pretty sure Rhino has all the necessary support for multiple global objects, including things like initStandardObjects.

The issue then is env.js itself, including the DOM. I believe the "right" way to do this (where possible) is to load independent versions of env.js into each window. I think that gets rid of all the scope bashing that Glen had to do in the earlier multi-window work. (You can't bash scopes (change them on the fly) in SpiderMonkey; it specifically says not to do this and some of its internal optimizations break if you do.)

There are a number of issues with this. It seems like I might have more flexibility in the Ruby/SpiderMonkey case than is available in the Rhino case, though from Chris's recent work, it seems like Rhino does provide a pretty rich API. There are also performance issues to loading all of env.js into every window. I played with sharing part of env.js (the DOM classes) while keeping the window state (including globals) entirely independent. This weakens isolation, which is why I was interested in what browsers let you do with the DOM classes/prototypes. I'd actually like to freeze/seal them but haven't gotten too far in that.

My current thoughts are that it would be nice if we could support a flexible enough platform API to allow the platform to decide how precisely to implement the browser model. There are constraints on how you create split objects in SpiderMonkey.

One side note: this doesn't address the weird stuff that the browser does with DOM-related scoping in on* handlers set to strings. That's pretty much a separate issue. I actually did this with nested "with" statements. I think that's reasonably clean and portable but I'd like somebody to double check that part.

Did I confuse things enough?