Promise handling algorithms are not very clear about what happens if type conversion fails

[domenic]

https://heycam.github.io/webidl/#dfn-perform-steps-once-promise-is-settled

What if the type is Promise<Node> and someone passes Promise.resolve(3)?

I think the best we can do is go down the rejection path? Although that makes using "upon fulfillment" in isolation pretty dangerous for non-any _T_s.

[domenic]

I am curious if implementations actually pay attention to the T at all... Do they have counterpart algorithms?

[bzbarsky]

Gecko pays attention to the T in the following ways:

1. IDL parse fails if Promise<T> is the return type of an operation or attribute but T is not exposed in all the globals where the operation or attribute is exposed. There is no corresponding requirement in the spec, as far as I can tell (also for the situation where some type is returned directly, without Promise being involved), but fundamentally it doesn't make sense to have this setup.
2. Something involving which C++ headers to include in generated binding files. I'm not even convinced that code needs to be there.
3. The equality operator on types in the IDL parser treats Promise<T> as equal to Promise<U> if and only if T == U. This equality operator is used when coalescing identical unions across IDL files. It could probably ignore the parameter type and just treat app Promise as equal in practice...

There are no other places that are aware of the T in Gecko as far as I can tell.

[annevk]

How does respondWith() work in Gecko? Is there a manual type check?

[Ms2ger]

In the spec as written, it'll return a rejected promise and the success steps won't be run.

Let's take a look at what APIs take a Promise argument anyway:

• ExtendableEvent.waitUntil: takes Promise<any>
• FetchEvent.respondWith: takes Promise<Response>; if the conversion fails, it wants to do the same as with a rejected promise.
• WebAssembly.compileStreaming and WebAssembly.instantiateStreaming take Promise<Response> and want the currently specced behavior (implemented in Fx, Chrome & Edge per wpt.fyi). Rejection steps just pass the rejection value through.
• MerchantValidationEvent.complete: takes Promise<any>
• PaymentRequestUpdateEvent.updateWith takes Promise<PaymentDetailsUpdate>; it wants to do nearly the same thing as when it gets a rejected promise, except that it drops the rejection value in a rejected promise in favour of an AbortError, while it passes along the TypeError from the conversion failure.

This suggests to me that we should run the rejection steps on conversion failure.

[bzbarsky]

How does respondWith() work in Gecko? Is there a manual type check?

Yes. See https://searchfox.org/mozilla-central/rev/7088fc958db5935eba24b413b1f16d6ab7bd13ea/dom/serviceworkers/ServiceWorkerEvents.cpp#576,588-591,595-597,605-608 (which checks that the resolution value is an object, then checks that it's a Response.

[domenic]

In the spec as written, it'll return a rejected promise and the success steps won't be run.

Ah, I guess because "converting" will throw, and PerformPromiseThen handles it. That makes sense.

This suggests to me that we should run the rejection steps on conversion failure.

Sounds good to me.