Safe Promise capabilities

[mhofman]

Given the feedback of #4, the discussion in #3 and in plenary led towards a potential "explicit" solution where a safe promise capability could be used selectively for places that must guarantee no reentrancy when handling a resolution value (and potentially this safe promise to be the default for spec operations).

From reading https://bugzilla.mozilla.org/show_bug.cgi?id=1923344, it is also my understanding it would be the only approach that would have protected against CVE-2024-9680 since the value there (an Animation) was expected to be thenable.

The precise behavior of the resolution functions of such a safe promise capability can be debated, but basically they must guarantee that no user code can be synchronously called. I am of the opinion that the sane approach is to delay by a tick in those cases, and to not introduce promises that fulfill to thenables (#5).

How such a safe promise capability is created is also up to debate. One option would be a new %SafePromise% constructor which reveals these safe resolution functions. Such a safe promise instance could maintain the appearance of being a regular %Promise% by having %SafePromise%.prototype = %PromisePrototype%, but that might interact negatively with the PromiseResolve mitigation also in scope (see tc39/ecma262#3662 (comment)) if we ever expose this %SafePromise% constructor to users (or expect spec code to call PromiseResolve with it)

[bergus]

I don't think a new constructor is a good idea. But what about exposing a new fulfill resolving function? It should not run the promise resolution procedure, it would simply fulfill the promise with the given value, not doing any inspection on it.

• Promise.withResolvers() would return { promise, fulfill, reject, resolve }
• Same for the spec-internal PromiseCapability records
• Promise.fulfill(x) would return a promise fulfilled with x
• The promise resolution procedure should not handle native promises as thenables (always - and repeatedly - testing their fulfillment results for thenability), it should get a new step to directly adopt native promises. Something like
  • "If isPromise(resolution), then
    1. if resolution.[[PromiseState]] is FULFILLED, then
       • Perform FulfillPromise(promise, resolution.[[PromiseResult]]).
    2. else if resolution.[[PromiseState]] is REJECTED, then
       • Perform RejectPromise(promise, resolution.[[PromiseResult]]).
    3. else (when resolution.[[PromiseState]] is PENDING)
       • Append a PromiseReaction Record { [[Capability]]: promise, [[Type]]: FULFILL, [[Handler]]: EMPTY } to resolution.[[PromiseFulfillReactions]].
       • Append a PromiseReaction Record { [[Capability]]: promise, [[Type]]: REJECT, [[Handler]]: EMPTY } to resolution.[[PromiseRejectReactions]].
    4. Return undefined.
• Similarly, the promise reaction job should forward results (when the [[Handler]] is EMTPY) directly to promiseCapability.[[Fulfill]] instead of [[Resolve]]
• In places where fulfill is not available but only resolve (e.g. it would be hard to introduce a third parameter for Promise constructor executor callbacks), it can be approximated with resolve(Promise.fulfill(value))

I think this would follow the spirit of the Promises/A+ spec and most original promise implementations best.

[mhofman]

As I mentioned in #5, I am not interested in introducing promises that can fulfill to thenable objects. If by any misfortune we ever end up going that direction, I would want it consistent, aka a native promise always attempts to unwrap that thenable object or not (unless the object itself mutates of course).

I only mentioned a constructor as a potential way to reveal the safe resolver functions (through the executor), as that is the main way to build a promise capability in the spec.

Imo a safe promise capability should not change the resolution semantics, except for the "timing" under which it perform the resolution so that it guarantees no synchronous reentrancy when calling the resolver functions.

[bergus]

I am not interested in introducing promises that can fulfill to thenable objects.

But why not? This would solve the actual underlying issue, and finally address the mistake made in ES6. It's a long-standing gripe the community has that the recursive resolution procedure makes promises non-monadic and makes it impossible to write generic functions involving Promise<T> with an arbitrary type T.

In #5 you claim

[The Promises/A+] Promise Resolution Procedure clearly state that values provided to a then's onFulfilled handler are recursively resolved, making it impossible for such values to become a fulfillment value of a spec compliant promise.

but that seems to be based on a misunderstanding. As @jridgewell also pointed out, this (recursive) resolution behaviour is only required to be applied on the return values from .then() callbacks, not on all values that any promise is ever resolved with. There is nothing wrong with such fulfillment values, these promise just have to be constructed by other means than .then().