New full Unicode for ES6 idea

Brendan Eich brendan at
Sun Feb 19 11:49:26 PST 2012

Mark S. Miller wrote:
> On Sun, Feb 19, 2012 at 12:33 AM, Brendan Eich <brendan at 
> <mailto:brendan at>> wrote:
> [...]
>     Why the global object? Because for many VMs, each global has its
>     own heap or sub-heap ("compartment"), and all references outside
>     that heap are to local proxies that copy from, or in the case of
>     immutable data, reference the remote heap. 
> [...]
> Is this true for same origin iframes? I have always assumed that 
> mixing heaps between same origin iframes results in unmediated direct 
> object-to-object access. If these are already mediated, what was the 
> issue that drove us to that?

Not all engines mediate cross-same-origin-window accesses. I hear IE9+ 
may, indeed rumor is it remotes to another process sometimes (breaking 
run-to-completion a bit; something we should explore breaking in the 
future for window=vat). SpiderMonkey just recently (not sure if this is 
in a Firefox channel yet) went to compartment per global, for good 
savings once things were refactored to maximize sharing of internal 

My R2 resolution is not specific to any engine, but I have hopes it can 
be accepted. It is concrete enough to help overcome large-yet-vague 
doubts about implementation impact (at least IMHO). Recall that 
document.domain setting may have to split a merged same-origin 
window/frame graph, at any time. Again implementation solutions vary, 
but this suggests cross-window mediation can be interposed lazily.

Another point: HTML5 WindowProxy (vs. Window, the global object on the 
scope chain) exists to solve navigation-away-from-same-origin security 
problems. Any JS that passes strings from one window to another must be 
using a WindowProxy to reference the other. There's a mediation point too.


More information about the es-discuss mailing list