Intent to Implement and Ship: WebAudio: Event Constructors

[Raymond Toy]

Contact emails

rt...@chromium.org, hong...@chromium.org

Spec

https://webaudio.github.io/web-audio-api/

https://webaudio.github.io/web-audio-api/#OfflineAudioCompletionEvent

https://webaudio.github.io/web-audio-api/#the-audioprocessingevent-interface---deprecated

Summary

Add constructors for the WebAudio events.

Motivation

Events are generally constructable, but the two WebAudio events were not.  This makes these events match the typical Event model.

See https://github.com/WebAudio/web-audio-api/issues/566 for the spec discussion.

Interoperability and Compatibility Risk

This is a new addition to the spec that will not affect backward compatibility.  We expect all browser to implement these constructors.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

http://crbug.com/662164

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5670531110010880

Requesting approval to ship?

Yes.

[Chris Harrelson]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Alex Russell]

Glad to see this. It's great to have platform consistency where possible.

[Rick Byers]

Adding constructors makes sense - thanks!  But as spec'd these don't yet follow the standard event construction pattern.  Filed https://github.com/WebAudio/web-audio-api/issues/1067

[Philip Jägenstedt]

LGTM2 with the spec fixed. I wouldn't mind looking at the CL, as it's surprisingly easy to get things around optional dictionary arguments and required dictionary members wrong. In particular, any event interface that has non-nullable attributes of interface type, which is true of both of these events, need to the corresponding dictionary members as required, or something magical would have to happen when calling the constructor without them.

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

LGTM1 with the spec fixed too (with foolip@ reviewing the CL - those sorts of easy mistakes are really the only concern with shipping this IMHO).

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

Seems like we're all pretty bad at counting :) LGTM1+2+1 = LGTM4.

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

Hah hah, sorry - I missed Chris's LGTM and thought you considered mine implied :-).

But yes, LGTM3 - you're good to go once you've landed a spec change that follows the event pattern used elsewhere.

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Raymond Toy]

Thanks so much for filing the issue.  We'll follow up on that before implementing this change in Chrome.

[Raymond Toy]

Definitely will add you to the CL.

One thing we forgot to mention.  With the deprecation of ScriptProcessorNode, AudioProcessingEvent is also deprecated.  We do this for completeness.

Also, OfflineAudioCompletionEvent is for when the offline context is finished.  We fully expect users to use the promise instead of the completion event.  The promise pattern is so much easier to use.

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

Yeah, event constructors aren't very useful. Or I guess a few of them are, like new Event('type'), and there's no place to draw the line, so they all get them.

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

I think they're most useful for composition scenarios - not common, but essential in some cases.  Eg. I often see code where one library is designed to be driven by MouseEvents, and some other library (or test cases) is driving the code by generating synthetic mouse events.  I think the same sort of scenario could apply for webaudio as well.

In general, it's important for composition, extensibility and testing that we give script a lot of the same power that the UA has, even though that's power that's rarely needed.

Rick

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.