Brendan Eich wrote:
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.
IOW, whether there' s a heap/compartment per global is not critical (but
if there is, then strings are already copied and could be transcoded as
to their meta-data distinguishing non-BMP+UTF16-aka-full-Unicode from
bad-ol'-90s-UCS2). The cross-window mediation via WindowProxy is.
The flag bits I mentioned could be combined: 1 flag bit for both
non-BMP-chars-in-this-string-*and*-full-Unicode-BRS-setting-in-effect-for-its-global.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
