Capture the incoming reason argument to
transform_stream_default_source_cancel_algorithm() on the
on_fulfilled_callback() of WebIDL::react_to_promise() on step 7.
When the min option is given the read will only be fulfilled when there
are min or more elements available in the readable byte stream.
When the min option is not given the default value for min is 1.
This AO can be used instead of CreateReadableStream in cases where we
need to set up a newly allocated ReadableStream before initialization of
said ReadableStream, i.e. ReadableStream is captured by lambdas in an
uninitialized state.
We enqueue a microtask for this readable stream AO, and the methods that
we call from the chunk steps manipulate promises. As such, we need to
enable callbacks for the entire microtask's temporary execution
context.
ReadLoopReadRequest::on_chunk expects an UInt8Array, so make sure we
convert the passed in ByteBuffer to an UInt8Array before passing it to
the AO writable_stream_default_writer_write.
Co-authored-by: Timothy Flynn <trflynn89@pm.me>
There were several instances where the spec marks an AO invocation as
infallible, but we were propagating WebIDL::ExceptionOr. These mostly
cannot throw due to knowledge about the values they are provided. By
unwinding these, we can remove a decent amount of exception handling.
There are a number of script-provided stream callbacks for various
stream operations, such as `start`, `pull`, `cancel`, etc. Out of all of
these, only the `start` callback can actually throw. And when it does,
the exception is realized immediately in the corresponding stream
constructor.
All other callbacks have spec text of the form:
Throwing an exception is treated the same as returning a rejected
promise.
And indeed this is internally handled by the streams spec. Thus all of
those callbacks can be specified as returning only a promise, rather
than a WebIDL::ExceptionOr<Promise>.
This changes the signature of queue_a_microtask() from AK:Function to
JS::HeapFunction to be more clear to the user of the functions that this
is what is used internally.
Switching away from SafeFunction immediately backfired here, as we're
dealing with two layers of captures, not one.
Let's do the correct fix, which is to use HeapFunction. This makes the
API and its behavior explicit, and keeps captures alive as long as the
HeapFunction is alive.
Fixes#23819.
Now that these algorithms are a HeapFunction as opposed to SafeFunction,
the problem mentioned in the FIXME is no longer applicable as these
functions are GC-allocated like everything else.
We were previously only returning the controllers current
[[byobRequest]] instead of taking into account pending pull intos.
Rename the getter function which would return the controllers
[[byobRequest]] slot to `raw_byob_request` to differentiate it from
the IDL getter.
This also leaves a FIXME for a spec step which we are also not currently
implementing correctly.
