Who uses the detach concept for ArrayBuffer?

[annevk]

We should remove https://heycam.github.io/webidl/#dfn-detach, but figuring out dependencies would be good. The main problem with the current prose is that DetachArrayBuffer can throw, as per whatwg/html#4601.

(I suspect at some point it might have been introduced for HTML, which does not use it at the moment.)

[Ms2ger]

@tidoust: would reffy be able to find dependencies of a term defined in the WebIDL spec?

[tidoust]

@Ms2ger No, Reffy is coarse-grained here. It does not track references to concepts defined in other specifications. The only thing you can get from Reffy is the list of known specifications that use ArrayBuffer (which you can simply get by searching files that include ArrayBuffer in IDL exports), but that won't tell you whether they reference the detach concept.

[bzbarsky]

I looked at where detaching actually happens in the Gecko implementation. Looks like it happens in the following places:

1. Structured cloning. In spec terms, looks like https://html.spec.whatwg.org/multipage/structured-data.html#structuredserializewithtransfer calls https://tc39.github.io/ecma262/#sec-detacharraybuffer directly.

2. WASM memory-wrangling bits. In spec terms, I think those bottom out in https://webassembly.github.io/spec/js-api/index.html#reset-the-memory-buffer which calls https://tc39.github.io/ecma262/#sec-detacharraybuffer directly.

3. Various Web Audio bits. https://webaudio.github.io/web-audio-api/#dom-baseaudiocontext-decodeaudiodata calls https://tc39.github.io/ecma262/#sec-detacharraybuffer directly. So does https://webaudio.github.io/web-audio-api/#acquire-the-content. Filed ConvolverNode's "buffer" attribute doesn't actually define the setter steps WebAudio/web-audio-api#1862 on the one underdefined bit and Need to handle DetachArrayBuffer throwing WebAudio/web-audio-api#1863 on the fact that they don't handle the throwing parts well.

As far as I can tell, that's it. There might, of course, be uses in drafts or specs that Gecko does not implement.

[annevk]

Okay, so I think we should be good removing this from IDL.

The one wrangle that remains is how good it is to call ECMAScript abstract operations on what are technically IDL objects, but I think we've largely decided to not care about that for now.

[domenic]

After the Web IDL rewrite in whatwg/streams#1035, streams would something similar to this: https://whatpr.org/streams/1035.html#transfer-array-buffer and various IsDetachedBuffer checks.

I guess it comes down to whether we want people to go through IDL prose, even in the [UnsafeReference] case from https://www.w3.org/Bugs/Public/show_bug.cgi?id=28798, or if Streams, Web Audio, and Web GL should instead down to the ES spec level.

[domenic]

Also part of this bug: the current sentence

Attempting to get a reference to or get a copy of the bytes held by a buffer source when the ArrayBuffer has been detached will fail in a language binding-specific manner.

is misleading since they don't really "fail", they just return zero-length byte sequences.

If we eliminate the term "detached" then we can eliminate this sentence and clear up the confusion.

[annevk]

I think we should aim to keep direct JavaScript dependencies to a minimum so we don't have to expand https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md#downstream-dependencies. Keeping JavaScript, IDL, and HTML updated is already enough of a pain as-is.

[domenic]

I started working on a PR for this and https://www.w3.org/Bugs/Public/show_bug.cgi?id=28798. However, I realized that everyone who wants to deal with detached buffers (namely, Streams) will be using [UnsafeReference] anyway. So we don't need the abstraction layer after all.

[domenic]

Hmm. Taking over this bug as the continuation of https://www.w3.org/Bugs/Public/show_bug.cgi?id=28798.

@annevk, the only non-Web GL user of [AllowShared] currently is https://encoding.spec.whatwg.org/. For encodeInto(), it seems you want to get a reference, so you'll use [UnsafeReference]. But for decode(), how do you want the spec prose to read there? Do you want a copy to be made automatically?

This impacts whether [AllowShared] automatically causes [UnsafeReference], or not.

[annevk]

If you're allowing shared memory I think you need to deal with a reference and make copies and such yourself.

We might also want to clarify what you have a reference to/copy of. For a copy we could return a byte sequence. But for a reference you need the byte sequence but also the object (or maybe just a way to detach it).

[kvark]

WebGPU uses the detach concept for array buffers representing the mapping of GPU data to CPU. It's essential for us to have an efficient implementation, since an alternative, if I understand correctly, would require a whole new copy of the data.

[annevk]

That seems fine, but it's problematic that it currently doesn't define define or reference "detach".

Also, I think I might come around to IDL providing primitives for this after all, similar to how it does for promises. We just need to be clear that the operation can throw and callers will need to deal with it.

[annevk]

This was fixed by #987. Thanks @domenic!