Re: [whatwg/webidl] "byte length of a buffer source type" needs updating for resizable and detached buffers (Issue #1385)

domenic left a comment (whatwg/webidl#1385)

Here is a concrete proposal for someone (not me) to implement, to bring specs in line with browser behavior:

1. Audit all operations in [#js-buffer-source-types](https://webidl.spec.whatwg.org/#js-buffer-source-types) to replace usage of raw [[ByteLength]] slots with TypedArrayByteLength, GetViewByteLength, or ArrayBufferByteLength as necessary.
2. Audit all operations in [#js-buffer-source-types](https://webidl.spec.whatwg.org/#js-buffer-source-types) to handle cases where IsDetachedBuffer() is true. The consensus seems to be to treat the results as zero-length buffers. This includes cases like making "byte length" return 0 and "get a copy of the bytes..." return a zero-length byte sequence.

At this point, at least [`textEncoder.encodeInto()`](https://encoding.spec.whatwg.org/#dom-textencoder-encodeinto) and [`textDecoder.decode()`](https://encoding.spec.whatwg.org/#dom-textdecoder-decode) will be fixed. (I.e.: instead of their current specs, which yield undefined behavior, their specs will match implementations.)

Further improvements:

3. Ensure there are WPTs for these cases in Encoding.
4. Fix the rest of the spec ecosystem to use the [#js-buffer-source-types](https://webidl.spec.whatwg.org/#js-buffer-source-types) operations, instead of what they are currently doing.
   - [Streams](https://streams.spec.whatwg.org/) currently manipulates the JS objects directly. It suffers from various problems because of this. /cc @MattiasBuelens
   - I suspect many other specs use quite vague language.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1385#issuecomment-3705337556
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1385/3705337556@github.com>