What realm should promises be created in?

[domenic]

There are several cases of interest:

1. Rejected promises created automatically by the Web IDL spec because of Web IDL-spec thrown exceptions, e.g. security check, bad this value, etc.
2. Rejected promises created automatically by the Web IDL spec when the operation/attribute description throws an exception and we convert that into a rejection. (Typically this is viewed as a backstop for bad spec-writing.)
3. Fulfilled promises created automatically by the Web IDL spec by converting the operation/attribute return into a Promise. (Per spec this happens every time, even if the operation/attribute returns a promise. That is a no-op if the promise constructors match, but do they? That's what we're discussing here.)
4. Promises created by the common phrase a new promise in specs.

In an offline discussion, it was mentioned there are specific issues for cross-origin access here, but I don't quite understand that as none of the safelisted cross-origin properties return promises.

Ideally all of these would be consistent (either current or relevant). Right now the situation is pretty unclear... One reading of the spec would say it should be current (based on ECMAScript defaults). But that isn't great for situations where a promise is cached, e.g. https://w3c.github.io/battery/#dom-navigator-getbattery. That spec specifically goes out of its way to use relevant, which seems fragile to require of all specs.

Another dimension of consistency is that we've decided exception objects should be created in the current realm.

Not sure what the right path is here.

/cc @yuki3 @bzbarsky

[domenic]

I think this is settled. Creating a promise now requires passing a realm explicitly, and this is done in the spec.