NewTarget check for AudioWorkletProcessor isn't actually possible with a Web IDL constructor

[bzbarsky]

https://webaudio.github.io/web-audio-api/#AudioWorketProcessor-constructors step 1 says:

Compare the value of NewTarget with the active function object; if the two are equal, throw a TypeError.

but there is no NewTarget or "active function object" available in a Web IDL constructor's steps. Those steps are handed the already-created to-be-initialized object and IDL values for the arguments; see https://heycam.github.io/webidl/#create-an-interface-object step 9.

Presumably this is trying to do something like what [HTMLConstructor] does, but note that this defined a separate extended attribute, with different semantics from IDL's [Constructor].

Is there a specific reason to disallow directly constructing AudioWorkletProcessor instances?

[hoch]

Previously:

• [audioworklet] Constructor of AudioWorkletProcessor #1447
• AudioWorkletProcessor NewTarget undefined #1900

[bzbarsky]

Yeah, so #1447 (comment) was just not correct. :(

[hoch]

Is there a specific reason to disallow directly constructing AudioWorkletProcessor instances?

Yes. AudioWorkletProcessor (render thread) is a counterpart of AudioWorkletNode (main thread). Without a node, a processor is meaningless because it can't be a part of the audio graph.

As we already have seen, the current text is based on #1447 (comment), and we'll appreciate the guidance to fix this. Perhaps things have changed over 2 years...

[bzbarsky]

Without a node, a processor is meaningless because it can't be a part of the audio graph.

OK, but is that a reason to prevent it being constructed, at the cost of specification and implementation complexity? If someone just constructs a processor, they can't do anything useful with it. Fine. That means no one will do that in practice...

But also, this approach doesn't actually solve that problem as described. If we take that current spec at face value, and code in the worklet does:

    class Foo extends AudioWorkletProcessor {};
    let foo = new Foo;

that is allowed by the current spec (because now NewTarget is Foo so https://webaudio.github.io/web-audio-api/#dom-audioworkletprocessor-audioworkletprocessor step 1 does not throw) and results in an AudioWorkletProcessor instance that is not hooked up to an AudioWorkletNode.

the current text is based on #1447 (comment)

That comment is wrong in terms of what things [Constructor] lets you specify and in terms of what [HTMLConstructor] actually is. It was wrong at the time too...

we'll appreciate the guidance to fix this

Here are some options:

1. Just allow AudioWorkletProcessor to be (uselessly) constructible. This is the simplest option in spec and implementation terms at first glance, though there might be some complications around the port stuff; see below.
2. Add a new extended attribute like [HTMLConstructor] that has the different semantics you want. That said, just doing a NewTarget check does not seem to give the semantics you want, per above.
3. Change the Web IDL spec to pass more information to IDL constructors (e.g. whether NewTarget was the constructor function itself). Again, this doesn't really let you solve the problem you describe, just like the current spec.
4. Solve this as part of fixing VUMeter example uses AudioWorkletProcessor's port in a way that can't work per spec #1973 by throwing from the AudioWorkletProcessor constructor if whatever magic out-of-band thing is being used to initialize the port is not available. This will make my new Foo example above throw, as well as new AudioWorkletProcessor. At least in general. What happens if Foo is registered as an actual processor and then the UA calls its constructor and that constructor does new Foo before calling super() is an interesting question that we're going to need to sort out for VUMeter example uses AudioWorkletProcessor's port in a way that can't work per spec #1973 anyway.

If we do any of options 1-3 we still have to figure out what happens with the port stuff in those cases, exactly, so we might end up at option 4 by default.

[hoch]

Thanks for your input. This is really helpful. I'll try to come up with a plan with the option 4.

[hoch]

Fixed by #2005. See: https://webaudio.github.io/web-audio-api/#audioworkletnode-processor-construction-data