search

w3c / webcodecs

WebCodecs is a flexible web API for encoding and decoding audio and video.
https://w3c.github.io/webcodecs/
Other
985 stars 136 forks source link

Task or microtask for invoking error callbacks? #711

Closed dalecurtis closed 1 year ago

dalecurtis commented 1 year ago

Spec language for invoking the error callback says to "queue a task": https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-task

Actually following this advice breaks some web platform tests. E.g., https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webcodecs/audio-encoder.https.any.js;l=196;drc=004515931845095d994006bca1401c3bf94ecb68

It seems reasonable to expect the error callback to have been delivered after awaiting flush; so I think we want to change the language around invoking the error callback to "queue a microtask": https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-microtask

@padenot @youennf @Djuffin @aboba

dalecurtis commented 1 year ago

Alternatively, we could invoke the error callback before rejecting pending flush promises.

Djuffin commented 1 year ago

Alternatively, we could invoke the error callback before rejecting pending flush promises.

I think that's what we should do

youennf commented 1 year ago

We generally tend to stay away from queuing micro tasks explicitly.

See discussion in https://github.com/web-platform-tests/interop/issues/382#issuecomment-1707164044 and https://github.com/web-platform-tests/interop/issues/382#issuecomment-1707195736, This would guarantee the flush promise to reject after the error callback is executed.

dalecurtis commented 1 year ago

This turned out to be a bug in our implementation, so I don't think we need to change this after all.