- From: Brendan Eich <brendan@mozilla.org>
- Date: Sun, 19 Feb 2012 11:58:38 -0800
- To: "Mark S. Miller" <erights@google.com>
- CC: "public-script-coord@w3.org" <public-script-coord@w3.org>, mranney@voxer.com, es-discuss <es-discuss@mozilla.org>
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
Received on Sunday, 19 February 2012 19:59:11 UTC