Add a "cancel" hook to "Transformer". This allows users to perform resource cleanup when the readable side of the TransformStream is cancelled, or the writable side is aborted.

To preserve existing behavior, when the readable side is cancelled with a reason, the writable side is always immediately aborted with that same reason. The same is true in the reverse case. This means that the status of both sides is always either "closed", "erroring", or "erroring" when the "cancel" hook is called.

"flush" and "cancel" are never both called. As per existing behavior, when the writable side is closed the "flush" hook is called. If the readable side is cancelled while a promise returned from "flush" is still pending, "cancel" is not called. In this scenario the readable side ends up in the "errored" state, while the writable side ends up in the "closed" state.

See https://github.com/whatwg/spec-factory for details.

This static method takes an async iterable and returns a ReadableStream pulling chunks from that async iterable. Sync iterables (including arrays and generators) are also supported, since GetIterator() already has all the necessary handling to adapt a sync iterator into an async iterator.

Closes #1018.

We skip two test files until the test infra and the spec/ref implementation gets updated.

Co-authored-by: Mattias Buelens <[email protected]>

 - Replace WritableStreamDefaultController's [[signal]] with
   [[AbortController]], using the controller's signal where [[signal]]
   was used. Signal abort on [[abortController]] rather than the
   [[signal]].
 - Remove the note about specs not signaling abort on the
   WritableStream's signal, since this won't be possible once
   AbortSignal's "signal abort" no longer exported.

The "transfer" stream type has been renamed to "owning". Change
streams-for-raw-video-explainer.md to match.

Follows whatwg/dom#1152, which will remove the "follow" operation. Also changes the "should not" to "must not".

Helps with whatwg/fetch#1610.

Co-authored-by: Domenic Denicola <[email protected]>

Also make the fetch() reference more precise.

This makes it easier for other specifications that use this algorithm, such as Fetch, to use streams while interfacing less directly with the JavaScript engine.

Helps with whatwg/fetch#1568. Helps with #1178.

Fixes #1246.

See https://github.com/whatwg/spec-factory for details.

See WICG/serial#165. This ends up adding two pieces of advice:

* One about how producers should wait on the promise returned by writer.write(), and how underlying sinks and transformers can use their promise return values to control that.

* One about how specification authors should avoid reading from chunks in parallel.

In #1214, ReadableStreamBYOBReadResult was changed to have a value property of type `(ArrayBufferView or undefined) value`, since it is possible for the value to be undefined.

However, the Web IDL specification says that is invalid IDL:

> undefined must not be used as the type of an argument in any circumstance (in
> an operation, callback function, constructor operation, etc), or as the type
> of a dictionary member, whether directly or in a union. Instead, use an
> optional argument or a non-required dictionary member.
>

https://webidl.spec.whatwg.org/#idl-undefined

So this instead removes ReadableStreamBYOBReadResult entirely, in favor of a renamed ReadableStreamDefaultReadResult, which has type any for its value.

Used, e.g., in WebTransport.

This includes tests for interaction between autoAllocateChunkSize and respondWithNewView, which were merged in web-platform-tests/wpt#32757. The reference implementation already passes them.

See WICG/serial#160.

The standard returns an ReadableStreamBYOBReadResult with an undefined
value, and the tests rely on this, but it wasn't permitted by the IDL. Fix the IDL
to match the actual behaviour.

Closes whatwg/webidl#1094.

See tc39/proposal-shadowrealm#331 for context.

See https://github.com/whatwg/spec-factory for details.

The user agent is allowed to use a default reader or a BYOB reader for the pipe, but we were always calling ReadableStreamDefaultReaderRelease in the finalize steps. This commit fixes the algorithm to we should use the appropriate release abstract operation corresponding to the chosen reader.

This was broken in d5f92d9.

Missed in d5f92d9.

Currently, reader.releaseLock() throws an error if there are still pending read requests. However, in #1103 we realized that it would be more useful if we allowed releasing a reader while there are still pending reads, which would reject those reads instead. The user can then acquire a new reader to receive those chunks.

For readable byte streams, we also discard pull-into descriptors corresponding to (now rejected) read-into requests. However, we must retain the first pull-into descriptor, since the underlying byte source may still be using it through controller.byobRequest. Instead, we mark this descriptor as "detached", such that when we invalidate this BYOB request (as a result of controller.enqueue() or byobRequest.respond()), the bytes from this descriptor are pushed into the stream's queue and used to fulfill read requests from a future reader.

This also allows expressing pipeTo()'s behavior more accurately. Currently, it "cheats" by calling ReadableStreamReaderGenericRelease directly without checking if [[readRequests]] is empty. With the proposed changes, we can safely release the reader when the pipe finishes (even if there's a pending read), and be sure that any unread chunks can be read by a future reader or pipe.

See nodejs/node#41048. This spells out the motivation for the difference between cancel and close/abort while we're here.

As discussed at last WebRTC/WHATWG Streams meeting, we are converging on a potential solution for VideoFrame handling in streams. This explainer is the first step towards a more formal solution.

* Use `fileHandle.close()` to close a FileHandle
* Pass a view to `fileHandle.read()`, since it doesn't accept an ArrayBuffer
* Pass `position` to `fileHandle.read()` instead of relying on implicit file positioning