Mark S. Miller wrote:
On Sun, Feb 19, 2012 at 12:33 AM, Brendan Eich <bren...@mozilla.com
<mailto:bren...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
