Repository navigation
Correct handling of resizable ArrayBuffer? #219
Description
Given const b = new Blob([A, B]), where A is a TypedArray with a resizable ArrayBuffer, what is the expected behavior?
Chrome/Firefox currently both throw an error if any of the source ArrayBuffer instances are resizable; other runtimes do not.
There is an issue here if A is resized while the Blob is being constructed and the data is being copied. This can happen, for instance, if B has a getter for it's length that causes A to be resized and the implementation uses a flow like...
let total = 0;
for (const chunk of chunks) {
total += chunk.length; // B could resize A as a side effect here
}
const dest = allocate(total);
for (const chunk of chunks) {
copy chunk into dest
}
Let's suppose that A and B both initially have length 10, but B's length getter resizes A to 5... what should the result be?
- Length 15, with 5 bytes from A, 10 bytes from B, allocation gets trimmed at the end of the copy
- Length 20, with 5 bytes from A, 10 bytes from B, and 5 zeroed bytes at the end?
- Length 20, with 5 bytes from A, 5 zeroed bytes, 10 bytes from B
- Error thrown because length changed?
- Something else?
What if A is resized larger? Is the result just truncated?
Should the spec for Blob explicitly make Chrome/Firefox's behavior of throwing immediately on resizable ArrayBuffer's standard? etc.
/cc @guybedford
Activity
annevk commentedon Apr 7, 2026
If
lengthhaving a side effect can cause issues for your implementation I think you've implemented it in the wrong way. Because that meanslengthcan also detach the buffer or change its values. Since[AllowResizable]is not specified the correct behavior here is aTypeError, but we should probably support them in some fashion.jasnell commentedon Apr 7, 2026
That's an obvious impl bug yes. That's not the question tho... the question is what is the correct behavior from a spec point of view. If
Since [AllowResizable] is not specified the correct behavior here is a TypeErroris the correct answer, that's what I need.I don't have an opinion myself on whether they should be supported and I'm perfectly fine saying they are not; but I think @guybedford might have an opinion from a WASM perspective.
guybedford commentedon Apr 8, 2026
I discussed whether this is expected to throw briefly with @syg and he seemed to indicate that if the implementations are able to support it correctly there is no reason the spec couldn't be changed to add the support.
For Wasm toolchains wanting to use resizable buffers by default, the use case would be passing a view into linear memory that is a temporary borrow of linear memory bytes, where the Blob constructor already does a copy so it would be wasteful to have to do two copies instead.
annevk commentedon Apr 8, 2026
See also discussion in whatwg/webidl#1487 & whatwg/webidl#1312. I think we mainly need someone driving this to a better overall state and implementations should follow.