Event constructors are missing arguments

[RByers]

The constructors added in #566 don't follow the pattern of other event constructors. I believe just saying [Constructpr]on OfflineAudioCompletionEvent means you can do new OfflineAudioCompletionEvent() but you can't do anything interesting with that because there's no good way to set the event properties (including the event type). Instead you want to take the event type string and a dictionary (which inherits from the EventInit dictionary) so that developers can do new OfflineAudioCompletionEvent("complete", {renderedBuffer: buf}).

Eg. see the definition of CustomEvent and MouseEvent.

[rtoy]

Yes, this makes sense to me and we should do this.

[joeberkovitz]

This was my mistake.

[hoch]

@RByers Rick, I have few questions on this - just to understand how this custom event works.

1. How do you target a certain OfflineAudioContext in the constructor of the event?
2. If you fire the event without specifying a target context, what happens?
3. What if the context is not started when an event is fired?
4. What if the context is still rendering the audio buffer when an event is fired?

I would love to change the name of the event to OfflineRenderCompletionEvent if the WG agrees.

[RByers]

How do you target a certain OfflineAudioContext in the constructor of the event?

All the constructor lets you do is initialize an event object, passing values through directly - exactly as the browser does internally. So you just accept values in the "Init" dictionary that correspond to each of the properties on the event. For OfflineAudioCompletionEvent it looks like that means you'd take a renderedBuffer dictionary member (which itself references an AudioContext, right?). There's no smarts needed in the event though - it's just a dumb container of information.

If you fire the event without specifying a target context, what happens?

Events are dumb, so if the event type allows renderedBuffer to be undefined (or null) then someone could generate such an event from JS using the constructor. That's fine. It's no different then, for example, some JS generating a MouseEvent with non-sensical values.

What if the context is not started when an event is fired?
What if the context is still rendering the audio buffer when an event is fired?

Again none of this should matter - the event is just a dumb container, doesn't interact with any of the webaudio code inside the UA itself. Sure if a library actually generated bogus events it might confuse some other JS on the page, but that's fine (no different from all the other ways one piece of JS can confuse another).

Think of it this way: a DOM event is just a generic notification with some particular bundle of information attached. The information flow is one way from the browser to JS via the events. Creating a synthetic event in JS is completely hidden from (and so irrelevant to) any of the browser WebAudio code.

[rtoy]

@joeberkovitz Since I was working on an intent to implement and ship for this in Chrome, I'm going to assign this to me, if you don't mind. Please feel free to change it back.

[rtoy]

The proposed constructors look like

Constructor(DOMString type, AudioProcessingEventInit eventInitDict)

dictionary AudioProcessingEventInit : EventInit {
    required double playbackTime;
    required AudioBuffer inputBuffer;
    required AudioBuffer outputBuffer;
};

and

Constructor(DOMString type, OfflineAudioCompletionEventInit eventInitDict)

dictionary OfflineAudioCompletionEventInit : EventInit {
    required AudioBuffer renderedBuffer;
};