On Tue, Feb 4, 2014 at 9:21 AM, Boris Zbarsky <[email protected]> wrote:
> On 2/4/14 12:08 PM, Kevin Reid wrote:
>
>> 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.
>>
>
> That's actually pretty complicated. Now you have two not-object-identical
> representations of windowB.postMessage in the scope of windowB, no? The
> current membrane in SpiderMonkey has a single per-global representation of
> each object, for sanity's sake. As a simple example, consider this code in
> window A:
>
> proxyForB.setTimeout(proxyForB.postMessage, 0, 5, "*");
>
> What function object should the setTimeout implementation see? What
> should happen when the timeout fires?
You point out that this is indeed more complicated to get “right” than I
had realized. I think it could still be done but things like setTimeout
would have to be proxied in the same way.
This arguably shows that the legacy policy is even more of a bad idea,
though, because it breaks a property kind of like TCP (I don't know a name
for it offhand, but it's related to the confused deputy). For example,
suppose that in windowB we previously evaluated
function later(f, ...as) { setTimeout(function() { f(...as); }, 0); }
and then in windowA we do
proxyForB.later(proxyForB.postMessage, 5, "*");
then if I understand your description correctly, this would perform a
postMesage from B's origin. But why should it, just because there's an
intervening user-defined HOF?
In particular, what if "later" instead is something that is built-in, _not_
defined by the DOM, but has the effect of calling a function passed in?
Whether or not one were to implement the mechanics in the way I propose,
there needs to be a well-defined and preferably sensible decision about
what happens upon something like:
proxyForB.Array.prototype.forEach.call([5], proxyForB.postMessage);
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
