Correct handling of resizable ArrayBuffer?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Quiet
- Tech stack
- javascript
- Domain
- web-dev
Research direction
The issue names no repository files or tests. Start by resolving the expected Blob construction behavior when a source TypedArray uses a resizable ArrayBuffer and is resized during copying, then document the chosen behavior and whether the specification should require an error or another result.
Written by the indexing model from the issue text.
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
- Dominant language
- HTML
- Stars
- 118
- Forks
- 52
- Avg merge
- 9d 16h
- Merged PRs (30d)
- 1
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from w3c/FileAPI
-
TPAC2026
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 1/5 Under an hour Newbie friendliness 62/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
[Block] Latest Posts [Type] Bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
t/bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
task
Difficulty 2/5 1-3 hours Newbie friendliness 86/100