Re: [heycam/webidl] Promise handling algorithms are not very clear about what happens if type conversion fails (#782)

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`](https://w3c.github.io/ServiceWorker/#dom-extendableevent-waituntil): takes `Promise<any>`
- [`FetchEvent.respondWith`](https://w3c.github.io/ServiceWorker/#fetch-event-respondwith): takes `Promise<Response>`; if the conversion fails, it wants to do the same as with a rejected promise.
- [`WebAssembly.compileStreaming`](https://webassembly.github.io/spec/web-api/#dom-webassembly-compilestreaming) and [`WebAssembly.instantiateStreaming`](https://webassembly.github.io/spec/web-api/#dom-webassembly-instantiatestreaming) take `Promise<Response>` and want the currently specced behavior (implemented in Fx, Chrome & Edge per [wpt.fyi](https://wpt.fyi/results/wasm/webapi/invalid-args.any.html?label=master&label=experimental&aligned)). Rejection steps just pass the rejection value through.
- [`MerchantValidationEvent.complete`](https://w3c.github.io/payment-request/#complete-method-0): takes `Promise<any>`
- [`PaymentRequestUpdateEvent.updateWith`](https://w3c.github.io/payment-request/#updatewith-method) 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.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/782#issuecomment-526519971