On Mon, Feb 3, 2014 at 4:56 PM, Boris Zbarsky <[email protected]> wrote:
> 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....
[...]
> 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.
>
Could not this be done while matching the above principle as follows?
proxyForB, or more precisely the proxy for the function object
(windowB.postMessage), does not actually invoke windowB.postMessage itself
but a corresponding "post message from origin A" function.
Or if the distinction should be made using 'this'-values rather than
function values, make it by the function proxy recognizing this=proxyForB
and not unwrapping it but performing the cross-origin post.
Either should be observably equivalent to the legacy behavior while not
introducing execution-context dependence.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
