Mark S. Miller wrote:
On Wed, Jul 31, 2013 at 5:00 PM, Brendan Eich <[email protected]
<mailto:[email protected]>> wrote:
Taking a tip from Mark and pulling my own words out of the
"Agreeing on user-defined symbols" thread:
This serialize point is good, and gets to something I raised with
Allen yesterday, which he originally stated: realms should be
*more* isolated. We may want distribuited (cross-machine) realms.
IE and other browsers may already do cross-process window.open,
returning a DCOM proxy or some such. SpiderMonkey in Firefox uses
membranes across all realm/global boundaries, even same-origin.
Given this, I think instanceof (or typeof with an extension that
must be realm-specific because implemented by user-code, or else
we have to reify the "world of realms" as discussed in the other
thread) breaking cross-realm could be addressed by saying "proxy
harder". IOW let's not complicate JS with realms, worlds, truly
global string to symbol registries, etc. etc.
Let's get back to the simplicity of same-realm as the normal case,
with few-and-legacy exceptions. Can we do it?
-----
Realms are a good addition but if browsers are all using membranes
cross-realm, then this enables us to do more via proxies
(wrappers) to satisfy user-facing API and built-in operator
constraints.
I think this is the legacy compat issue that may tie our hands here.
As I understand it, all browsers enable cross realm intimate mixing of
object graphs via same origin iframes. Firefox does impose a membrane
boundary here. I believe WebKit does not. I do not know what IE does.
I would guess that Opera now does whatever WebKit does.
You mean Blink :-P -- now diverging from WebKit, including in DOM
implementation. I believe now the native (C++-implemented) DOM stuff
implements the needed tracing GC hooks to avoid cyclic leaks through
reference-counted and V8-rooted edges.
Anyway, the point is browsers have changed over the years, and membranes
and proxies -- including WindowProxy codified by HTML5 -- are now
common. Can we make use of this?
The reason FF does is because of the %^##*^&%&(*#@#&
Tell me how you really feel :-P
But no, this is not why we use membranes across all real/global
boundaries. We do it for performance, to make the global object and its
"compartment" 1:1.
origin truncation kludge that the web still continues to support,
where two frames that are same origin at t-zero may become different
origin at t-one. FF revokes inappropriate inter-realm access at that
point, because such access would then violate same origin separation.
I don't know how browsers without such inter-frame membranes cope with
the sudden need to impose origin separation that cuts through an
entangled object graph, but presumably in an observably different
manner. I also have no idea what html5 specifies must be done in this
situation.
HTML5 specifies document.domain fully:
http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html
In any case, as long as these realms remain same origin, I believe all
browsers act compatibly. This requires that the membrane used by FF be
fully transparent until revoked, so that it acts identically to the
lack of a membrane on the other browsers.
Please, anyone who knows the actual situation should speak up, either
to correct or confirm what I'm saying, because I'm really uncertain
about this. What's the actual situation?
I know you hate document.domain, but as noted above, it's not the
proximate cause of our compartment-per-global model. Also, I'm told even
IE9 could remote window.open cross-process, which really isolates realms
even if same-origin. (But perhaps it doesn't remote unless
different-origin?)
So yes, calling all implementors. Cc'ing a few.
/be
If I'm right that user-extensible methods and values, including
typeof customization, require either realm-sensitivity or else
world-of-realms spec and even more user-facing complexity, then we
also ought to think twice about the "isolate realms harder" option.
/be
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
