AudioWorkletProcessor should extend EventTarget if 'message' events can be dispatched to it

[smaug----]

Currently it is very much underdefined how AudioWorkletProcessor.onmessage is supposed to behave. AudioWorkletProcessor.postMessage sends some data which onmessage is supposed to get, but since onmessage is type EventHandler, something somewhere is supposed to dispatch an event, probably 'message' event using MessageEvent interface.

[smaug----]

or, since AudioWorkletProcessor is apparently something JS is supposed to extend, it needs to be defined somehow that onmessage is something which is called when event is dispatched.

But events need to be dispatched to some target, so what should event.target point to?

... this all is very unclear still in the spec.

[hoch]

Yes, the current PR is not clear about the behavior of message passing. It vaguely mentions that it is similar to how Worker behaves, but it is not true. (That part came from the previous AudioWorker spec proposal)

This is partly because of the infancy of Worklet spec work. Note that the message passing in Worklet is not considered or defined yet. Also please take a look at my alternative idea is to ditch the conventional message passing. (#936)

[hoch]

Let me revisit this since we decided to throw away the alternative design in #936.

We might have to invent the notation for the messaging system in AudioWorklet. There is an implicit association between a pair of instances of AudioWorkletNode and AudioWorkletProcessor that are created by a single constructor call. Therefore,

AudioWorkletNode_A.postMessage() will be routed to AudioWorkletProcessor_A.onmessage, and AudioWorkletProcessor_A.postMessage()' will go toAudioWorkletNode_A.onmessage()`.

The IDL notation for this messaging relationship is yet to be written, so please feel free to suggest ideas if you have any.

[hoch]

Fixed by #963.