I don't see the confusion here. The promises spec is explicit that it calls the passed function's internal [[Call]] method, with `undefined` as `thisArgument`.
Are you saying that [[Call]] is not well-defined for `window.postMessage.bind(window, 5, "*")` or for `set.bind(location, "relativeURI")`? That seems strange. If that's the case the passed objects will not pass the IsCallable tests. But I don't believe any browsers behave this way. ________________________________________ From: es-discuss <[email protected]> on behalf of Boris Zbarsky <[email protected]> Sent: Monday, February 03, 2014 12:53 To: Anne van Kesteren Cc: EcmaScript Subject: Re: Specification styles On 2/3/14 12:35 PM, Anne van Kesteren wrote: > Could you maybe give an explicit example? I think that would help in > understanding the bug in the promises specification. I suspect not > everyone here is familiar with what you are referring to. Sure. Given a promise named "somePromise", something needs to define the behavior of the following two cases: 1) somePromise.then(window.postMessage.bind(window, 5, "*")); 2) var set = Object.getOwnPropertyDescriptor(location, "href").set; var navigate = set.bind(location, "relativeURI"); somePromise.then(navigate); The incumbent settings object (aka "the script you were called from") defines the behavior of case #1: it determines the .origin property of the resulting MessageEvent. The entry settings object (aka "that weird backwards-compat thing Location needs, which is kinda where you entered JS execution from browser code, whatever that means") defines the behavior of case #2: it determines the base URI used for resolving the "relativeURI" string. My real point was that we don't want to make every single specification writer worry about edge cases like this and various other ones scattered about the web platform unless we absolutely have to. Especially since the "sane" behavior in the cases above is not trivially obvious. -Boris P.S. For the record, if Promise.prototype.then took a WebIDL callback as an argument the behavior would be as follows: In case 1 the origin is the origin of the incumbent settings object at the time the "then()" call was made. If that happened from a script, it's the origin of that script; if it happened via more bind/callback games then it depends on what those callbacks pushed on the script settings stack. In case 2 the base URI is the base URI of the global associated with the "navigate" Function object. P.P.S. You can add some curliques to case #2 by grabbing the setter from one global, the location object from a second global, calling Function.prototype.bind from a third global, having the promise come from a fourth global, having the "then" method come from a fifth global and binding it to the promise using Function.prototype.bind from a sixth global. Just to keep people on their toes and all. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
