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. /beReceived on Sunday, 19 February 2012 19:59:11 UTC
This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:46 UTC