Globals specified with `[Exposed=*]` not present in `AudioWorkletGlobalScope`

[Liamolucko]

Describe the issue

There are several globals such as TextEncoder, TextDecoder and URL which seem to have been intentionally left out of AudioWorkletGlobalScope. However, these are specified with [Exposed=*] in WebIDL, which is defined as:

• If the [Exposed] extended attribute takes a wildcard
  • The own exposure set is the set of all global names of all interfaces which have the [Global] extended attribute.

The definition of AudioWorkletGlobalScope uses [Global], so should technically contain these:

[Global=(Worklet, AudioWorklet), Exposed=AudioWorklet]
interface AudioWorkletGlobalScope : WorkletGlobalScope {
  undefined registerProcessor (DOMString name,
                               AudioWorkletProcessorConstructor processorCtor);
  readonly attribute unsigned long long currentFrame;
  readonly attribute double currentTime;
  readonly attribute float sampleRate;
};

To be clear, I'm not saying they should be added to AudioWorkletGlobalScope; I'm saying that it needs to be specified somewhere that they aren't there.

It's possible I may have just missed a note about this somewhere in the spec, but I couldn't find anything.

Where Is It

I'm not entirely sure whether this should be fixed in the Web Audio spec itself or the specs which define these globals with [Exposed=*].

Some possibilities, though:

• AudioWorkletGlobalScope
• WorkletGlobalScope
• TextEncoder
• TextEncoder
• URL

[hoch]

As you mentioned, the WG's intention is to limit the exposure of AudioWorkletGlobalScope only for the worklet-based audio processing. I am not sure if there's a way to notate the exception of specific Globals using WebIDL.

It also seems like there's inconsistency between the spec and the actual implementation:
Chrome's IDL
FireFox's IDL

We'll triage this issue in the next teleconference and think about solution.

[guest271314]

See also WebAudio/web-audio-api-v2#79 re WebAssembly.compileStreaming() and WebAssembly.instantiateStreaming(). Both are defined/exposed on the WebAssembly object in AudioWorkletGlobalScope, neither works as intended because Response is not exposed in AudioWorkletGlobalScope.

Although OP states

To be clear, I'm not saying they should be added to AudioWorkletGlobalScope; I'm saying that it needs to be specified somewhere that they aren't there.

for completeness an encoding polyfill can be used. I modified https://github.com/inexorabletash/text-encoding/blob/master/lib/encoding.js in order to import TextEncoder and TextDecoder into a QuickJS application by substituting globalThis for this and including this at the end of the script

const {TextEncoder, TextDecoder} = globalThis;
export {TextEncoder, TextDecoder};

which we can import into AudioWorkletGlobalScope

import {TextEncoder, TextDecoder} from './encoding.js';
console.log(TextEncoder, TextDecoder);
const encoder = new TextEncoder();
const decoder = new TextDecoder();
let data = encoder.encode('abc');
console.log(data);
console.log(decoder.decode(data));

encoding.js.zip. There are polyfills for URL, e.g. https://github.com/lifaon74/url-polyfill, which can be adjusted and imported similarly. Polyfilling Response is more involved.

[guest271314]

Technically we can encode and decode strings with the following alone

let encoded = new Uint8Array([97, 98, 99]);
let str = String.fromCharCode(...encoded);
let encode = new Uint8Array([...str].map((s) => s.charCodeAt()));
console.log({encoded, str, encode});

[hoch]

@Liamolucko It looks like we need to open issues against TextEncoder and URL specs. Could you do that?

[inexorabletash]

FYI, TextEncoder/TextDecoder were made [Exposed=*] here whatwg/encoding@f09648a with discussion at tc39/proposal-shadowrealm#331 - TL;DR there are a set of APIs specified as Web APIs that could just as easily have been specified as parts of ECMAScript (streams, encoding, URL, etc) and it was felt that these should be present in every context.

So... might require discussion w/ TC39 folks etc. if you want to revisit that.

[inexorabletash]

More specifically: if you have a reason to exclude these APIs, it would follow there are parts of ECMAScript that perhaps you'd also want to exclude (e.g. parts of ECMA-402 Internationalization?), now or in the future.

[hoch]

That's a good point. Thanks @inexorabletash!