Re: New full Unicode for ES6 idea

Mark S. Miller wrote:
> On Sun, Feb 19, 2012 at 12:33 AM, Brendan Eich <brendan@mozilla.com 
> <mailto:brendan@mozilla.com>> 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 
immutables.

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.

/be

Received on Sunday, 19 February 2012 19:49:57 UTC