Uses of "resolving x as a promise" and so forth need to specify the global

[bzbarsky]

For example, https://streams.spec.whatwg.org/#ws-constructor step 14 says:

the result of resolving startResult as a promise

and I assume they mean http://www.w3.org/2001/tag/doc/promises-guide#resolved-as-a-promise but it's not clear which global's initial value of Promise.resolve should be used. Plausible things are the current Realm's global or some canonical global associated with the object that's creating the Promise, depending on whether we want the exact promise to depend on where the function being called came from or on whether we want it to depend on where the object the function is manipulating came from...

Note that for IDL-defined APIs that return a non-NewObject Promise we probably want the global of this; for NewObject ones current Realm might make sense.

[domenic]

Good catch.

So to me the most intuitive thing would be to model this as WritableStream() being self-hosted in a file that looks something like this:

// save copies of globals
const Promise_resolve = Promise.resolve.bind(Promise);

class WritableStream {
  constructor(...) {
     ... Promise_resolve(startResult) ...
  }
}

I think this would mean "current Realm" assuming we allow UA code to have a current Realm. Per the ES spec I think it should: https://tc39.github.io/ecma262/#sec-built-in-function-objects-call-thisargument-argumentslist step 5/6/9 sets up the current execution context from which the current Realm is derived.

Do you agree? This confuses me a bit:

Note that for IDL-defined APIs that return a non-NewObject Promise we probably want the global of this; for NewObject ones current Realm might make sense.

If UA code has a current Realm then these should be the same. Maybe you are thinking of an edge case that I am missing?

---

Of course this problem generalizes to a lot of places in a lot of specs which create objects without saying where they came from. Can we try to establish a default (here for now, but later in IDL)? Current Realm seems good?

---

Finally that particular example is interesting because I don't think [[startedPromise]] is ever observable.

[bzbarsky]

UA code should have a current Realm yes, per exactly the spec section you cite. At least once we define all IDL stuff to be built-in function objects.

Maybe you are thinking of an edge case that I am missing?

I'm just thinking of the obvious interesting case: window1.SomeInterface.prototype.someMethod.call(SomeInterfaceInstanceFromWindow2). In this case the this value's global is window2 but the current Realm is that of window1.

What I would basically like to avoid is situations where doing that on an object causes it to create something in the global of window1 and cache it in an internal slot, so that all callers after that see it as coming from window1: this seems like it would lead to behavior depending on who happened to call things on the object first. Which is why for NewObject stuff I think it's fine to use the current Realm but for things that get cached I think we should use the global of this. Yes, this does mean self-hosted code would need to do something interesting to extract this global from this and then get its original Promise.resolve value...

Finally that particular example is interesting because I don't think [[startedPromise]] is ever observable.

Ah, then it doesn't matter which global is used for it. That was just an example that prompted me to look at the definition of "resolving as a promise" and realize that consumers that do care need a way to control which global it uses.

[bzbarsky]

It would be really nice to make some progress here. We're trying to design some security infrastructure in Gecko, and how exactly we go about doing it partly depends on how Promise-returning methods actually create their Promise implementations.

[domenic]

Fixed by whatwg/webidl#490 !