On 2/3/14 3:55 PM, Allen Wirfs-Brock wrote:
Do me this seems style should be considered an anti-pattern as the then
contract is for a function that does not require a this value.
Sure. No one in their right mind would write it that way. Except
insofar as they're trying to get particular security behavior...
They could be more concisely and clearly restated as:
1): somePromise.then(() => window.postMessage(5, "*"));
2): somePromise.then(() => location.href = "relativeURI");
Am I misunderstanding something about these?
These actually have somewhat different behavior from the bind case.
Specifically, the origin that the postMessage sees in the arrow function
acse right now will be that of the arrow function passed to then() in
this case (or whatever JS function it is that invokes postMessage if
it's a JS function with actual JS code that invokes it). This is not
necessarily the same as the origin of the code that called then()...
I'm not sure whether that's in fact the behavior we want for arrow
functions... but certainly in general if I have some code in window A
that calls then() and passes to it a function from window B that then
calls postMessage on window C, we want the message to be coming from B,
not from A. Or so I'm told.
Realms don't directly expose those concepts (that would be pretty host
platform dependent) but they do have a global object upon which
properties can be predefined and they allow for association with a
Loader that might be host specific and have such state.
OK, great. ;)
If there needs to be hooks (in [[Call]] or anywhere else) we should be
able to describe those hooks in a way that is meaningful and offer
potential utility to other kinds of hosts. How would you abstractly
describe you requirements?
Requirement #1: When some actual JS code someone typed into a <script>
tag calls postMessage on some Window object, the origin needs to be the
origin of the JS code in question.
Requirement #2: When some actual JS code someone typed into a <script>
tag calls the location.href setter, the base URI needs to be the thing
that's compatible with what UAs do (which in practice means "the base
URI of the window where we last called from C++ into JavaScript)...
Yes, this sucks, I'm sorry.
Requirement #3: We need to extend these definitions to all cases where
these functions can be called, even if there is no actual script someone
typed into a <script> tag that is calling them.
I'm not sure how to describe all this for an environment that doesn't
have postMessage or a location setter, honestly. In particular, the
location setter behavior is purely compat with insanity. :(
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18242 has some of the
relevant discussion, if that helps, for the postMessage case.
Unless I missed something, the use of bind just obscured the point you
were really trying to make.
I needed a way to have the browser asynchronously invoke the method in
question in a context where the phrase "script that invoked the method"
(which is what postMessage used to be defined in terms of) is
nonsensical. Unfortunately, in the arrow function case it's perfectly
well-defined what the "script that invoked the method is", so the arrow
function version doesn't actually exercise the edge case I wanted to
exercise.
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
