search

whatwg / dom

DOM Standard
https://dom.spec.whatwg.org/
Other
1.57k stars 290 forks source link

Is it intentional to not expose AbortSignal to Worklets? #937

Open saschanaz opened 3 years ago

saschanaz commented 3 years ago

A worklet has EventTarget#addEventListener but it cannot use AbortSignal to batch-remove them. Is this intentional?

annevk commented 3 years ago

I guess we should add this to AudioWorklet as well then.

cc @padenot

padenot commented 3 years ago

We probably can use this in a few places indeed.

@hoch, I'm thinking about OfflineAudioContext rendering cancellation, decodeAudioData, etc. Unclear for AudioWorklet, maybe it can be useful.

hoch commented 3 years ago

Interesting. How one would associate an AbortController with OfflineAudioContext.startRendering() and BaseAudioContext.decodeAudioData()?

Like @padenot mentioned, I am also not sure what this means to non-main thread Worklets.

annevk commented 3 years ago

I don't see Paul mentioning that? In any event, given that we expose events in audio worklets, it seems we should expose this as otherwise addEventListener() is less functional in audio worklets and that would be confusing.

(If you want other APIs to adopt this as well, typically you would make them accept a dictionary with a signal member, as addEventListener() and fetch() do, for instance.)

hoch commented 3 years ago

I was simply agreeing to the comment "Unclear for AudioWorklet".

Thanks for the explanation, @annevk!