Fix assertion failure in RespondInternal after transferring array buffer in RespondWithNewView

[nidhijaju]

While implementing #1123 in Chrome, I realised that calling RespondInternal(controller, view.[[viewByteLength]] after calling TransferArrayBuffer(view.[[ViewedArrayBuffer]]) makes the assertion in RespondInternal(), specifically Assert: bytesWritten > 0, fail. This is because view.[[viewByteLength]] becomes 0 after transferring the array buffer.

This can either be solved by not using TransferArrayBuffer() (which was the case before) or by storing the view.[[viewByteLength]] first before transferring the buffer. In this PR, I've taken the latter approach.

@MattiasBuelens I'm wondering if you have any context on why we changed the standard to use TransferArrayBuffer() in RespondWithNewView()?

---

Preview | Diff

[MattiasBuelens]

Good catch! 👍 The reference implementation doesn't correctly implement TransferArrayBuffer, so it's hard to catch these kinds of errors before browsers start implementing. (self.structuredClone() would help here, but #1233571 is still open. 😛)

Could you update the reference implementation to reflect the spec text changes?

@MattiasBuelens I'm wondering if you have any context on why we changed the standard to use TransferArrayBuffer() in RespondWithNewView()?

When you respond to a BYOB request, we must immediately take back control of the buffer so we can (later on) give it back to the initiating read-into request. If we didn't transfer the buffer immediately, then you could do something like:

const view = controller.byobRequest.view;
view[0] = 12;
controller.byobRequest.respondWithNewView(view.subarray(0, 1));
view[0] = 34; // shouldn't be possible!

[nidhijaju]

Could you update the reference implementation to reflect the spec text changes?

Done :)

Thank you for the explanation!

[ricea]

lgtm