New full Unicode for ES6 idea
brendan at mozilla.com
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 mozilla.com
> <mailto:brendan at 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
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