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.

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. ```js
   somePromise.then(window.postMessage.bind(window, 5, "*"));
  ```

2. ```js
   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.

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.