On 2/5/14 1:02 PM, Kevin Reid wrote:
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.
Correct. In fact, you don't even need the setTimeout. Just this in
windowB:
function doNow(f, ...as) {
f(...as);
}
and then windowA doing:
proxyForB.doNow(proxyForB.postMessage, 5, "*")
would have the same effect: the message would seem to come from windowB...
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?
The way HTML5 attempts to define things right now is that if your
"later" or my "doNow" is built-in as opposed to explicitly written in
script then the message will come from window A.
This is unfortunately gross, I agree...
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);
Right. That's what led to the concept of the script settings stack...
The behavior here is in fact well-defined-ish, but it relies on this
distinction between scripted and built-in functions. I believe the
relevant text at
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#calling-scripts
is this:
When a JavaScript SourceElements production is to be
evaluated, the settings object of the script corresponding to
that SourceElements must be pushed onto the stack of script
settings objects before the evaluation begins, and popped when
the evaluation ends (regardless of whether it's an abrupt
completion or not).
Again, this doesn't so much make me happy; it's just the best people
have come up with so far.
In this case, since there is no SourceElements involved in
Array.prototype.forEach (lots of handwaving involved in _that_ claim!)
there would be no change to the script settings stack when forEach is
invoked, so the message would be posted in the same way as if the
forEach caller had directly invoked postMessage.
Yes, this means that if you replace forEach with a scripted version you
get different behavior. :( I'd love a consistent proposal that avoids
that problem that browsers that aren't currently using any sort of
membranes for their DOM are actually willing to implement.
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
