[w3c/FileAPI] Correct handling of resizable ArrayBuffer? (Issue #219)

jasnell created an issue (w3c/FileAPI#219)

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?

1. Length 15, with 5 bytes from A, 10 bytes from B, allocation gets trimmed at the end of the copy
2. Length 20, with 5 bytes from A, 10 bytes from B, and 5 zeroed bytes at the end?
3. Length 20, with 5 bytes from A, 5 zeroed bytes, 10 bytes from B
4. Error thrown because length changed?
5. 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

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/219
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/issues/219@github.com>