wasm: streaming APIs accept non-Uint8Array response body chunks

Version

latest main branch

Platform

7.1.3-arch1-3

Subsystem

wasm

What steps will reproduce the bug?

const bytes = new Uint8Array([
  0x00, 0x61, 0x73, 0x6d, // \0asm
  0x01, 0x00, 0x00, 0x00, // version 1
]);

const stream = new ReadableStream({
  start(controller) {
    controller.enqueue(bytes.buffer); // ArrayBuffer, not Uint8Array
    controller.close();
  },
});

const response = new Response(stream, {
  headers: {
    'Content-Type': 'application/wasm',
  },
});

WebAssembly.compileStreaming(response).then(
  () => console.log('unexpectedly compiled'),
  (error) => console.error('rejected:', error),
);

How often does it reproduce? Is there a required condition?

Every

What is the expected behavior? Why is that the expected behavior?

Fetch body consumption requires every chunk read from the response body to be a Uint8Array. Other values, including ArrayBuffer, DataView, and other typed arrays, should cause the operation to reject with a TypeError.

What do you see instead?

WebAssembly.compileStreaming() and WebAssembly.instantiateStreaming() accept response bodies whose
ReadableStream produces non-Uint8Array chunks.The WebAssembly module is compiled successfully, even though the response body produces an ArrayBuffer chunk.

Additional information

Refs: https://github.com/web-platform-tests/wpt/blob/master/wasm/webapi/wasm_stream_compile_test.any.js#L80-L93
Refs: https://github.com/web-platform-tests/wpt/blob/master/wasm/webapi/wasm_stream_instantiate_test.any.js#L79-L92

Start with the WebAssembly.compileStreaming() and WebAssembly.instantiateStreaming() entry points and the referenced WPT tests, wasm/webapi/wasm_stream_compile_test.any.js and wasm/webapi/wasm_stream_instantiate_test.any.js. Reproduce the ArrayBuffer-chunk case from the report, then verify that non-Uint8Array response chunks reject with a TypeError while valid chunks continue to work.