On 2/3/14 7:46 PM, Kevin Reid wrote:
It is an extremely bad idea to have the consequences of a function call
depend on properties of the caller rather than of the function and the
arguments.
I agree, but the postMessage API is what it is....
Even if it proves necessary for legacy compatibility, no such behavior
should be specified in new systems.
I believe the postMessage behavior is all about legacy compatibility. as
is the Location href setter behavior. Sadly, it's not the only legacy
thing in the platform that needs that behavior. :(
So really, for each function call there are three relevant globals: the
global of the function itself and the entry and incumbent globals at the
callsite.
I think I heard that Firefox already handles this via a membrane
('otherWindow' is not actually the same as that window's 'window'
object, but you can't tell because they're substituted as needed when
passed across origins); can someone confirm this?
Firefox has a membrane here, but the call actually pierces the membrane
in this case, so when Firefox needs to find out who "the caller" was it
actually just examines the callstack (modulo the cases when called with
no script on the stack, etc).
Specifically, in Firefox if code in window A has a reference to window
B, then it actually has a reference to a proxy. If it then does
proxyForB.postMessage that returns a proxy for the actual
windowB.postMessage method. When [[Call]] happens on this proxy, it
checks that you're allowed to make the call at all, then invokes
windowB.postMessage, passing to it proxies to the arguments it was
called with.
But now the windowB.postMessage method would like to determine who
called it... and that information is no longer available from itself,
since it itself lives in window B.
-Boris
P.S. Boy do I wish people had mutated the subject when taking the
discussion in this direction. Not really worth doing it now...
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
