Previously, the validator had a lot of extraneous information related to
frames. Now, there's just one stack with all the necessary information
derived from it.
(cherry picked from commit ad54b69de9df6ccd44178cbe49779e313f95f273)
Previously, `memory.fill` filled memory with 4-byte values, even though
`memory.fill` should fill with just one byte. Also fixes some other
issues with some of the bulk memory instructions, like `memory.init`.
(cherry picked from commit d8ee2e343df25d12637e08d54908b4fd86a22dc3)
We don't have asynchronous TCP socket implementation, so its usefulness
is a bit limited currently but we can still test it using memory
streams. Additionally, it serves as a temporary {show,test}case for the
asynchronous streams machinery.
This class allows to convert an asynchronous generator which generates
chunks of data into an AsyncInputStream. This is useful in practice
because the said generator often ends up looking very similar to the
underlying synchronous algorithm it describes.
With Ladybird now being its own repository, there's little reason
to keep the Ladybird Android port in the SerenityOS repository.
(The Qt port is useful to be able to test changes to LibWeb in lagom
so it'll stay around. Similar for the AppKit port, since getting
Qt on macOS is a bit annoying. But if the AppKit port is too much
pain to keep working, we should toss that too.
Eventually, the lagom browser ports should move out from Ladybird/
to Meta/Lagom/Contrib, but for now it might make sense to leave them
where they are to keep cherry-picks from ladybird easier.)
Updating these steps enables the writable side of a TransformStream to
raise the cancel callback when it's aborted.
(cherry picked from commit 6d7885e25036bf08e31f2ad7a13db31767deabaf)
This adds internal slots [[cancelAlgorithm]] and [[finishPromise]] to
TransformStreamDefaultController.
(cherry picked from commit ff5be1fd363c4cb9ba510679b1ee65a0c0b10bc2)
No longer just for response headers! The same type is obviously useful
and ergonomic when making requests as well.
(cherry picked from commit 260c5c50ad19f19d0d4c30984e512f56c055ecff)
Updated various SerenityOS components to make it build.
Before we had HTTP::HeaderMap (which preserves multiple headers with the
same name), we collected multiple "Set-Cookie" headers and bundled them
together as a JSON array.
This was a huge hack, and now we can stop doing that, since LibWeb gets
access to the full set of headers now.
(cherry picked from commit 5ac093885922246529a467054888e598f8832450)
Instead of using a HashMap<ByteString, ByteString, CaseInsensitive...>
everywhere, we now encapsulate this in a class.
Even better, the new class also allows keeping track of multiple headers
with the same name! This will make it possible for HTTP responses to
actually retain all their headers on the perilous journey from
RequestServer to LibWeb.
(cherry picked from commit e636851481eabdf00953573a5eb459ee52feeacc)
Updated various SerenityOS components to make it build.
Fetch: Make sure we iterate over HeaderMap's headers()
This fixes a build failure when built with CMake option
'-DENABLE_ALL_THE_DEBUG_MACROS=ON'.
(cherry picked from commit c51d01bea712d75f9b2cd700be942935044e49b4)
This supports opacity via the standard method of painting stacking
context to a new bitmap, then blitting it back when popping the stacking
context.
One extra complication is we have to ensure clipping is flushed between
any change of the target bitmap. But other than that is all standard.
This adds two paths for clipping. If the clip rect is known to be
rectangular (and axis-aligned), then normal/fast painter clipping is
used. Otherwise, a temporary buffer is made for 'expensive' clipping
(i.e. clipping by an arbitrary quadrilateral). All draw commands are
then redirected to the temporary buffer until the clipping needs to be
flushed. Clipping is flushed when the clip rect or target bitmap
changes. Flushing expensive clipping requires applying a clip mask to
the temporary buffer, and then blitting it to the target bitmap.
Note: If the bounds of a draw command are known to be within the current
clip 'expensive' clipping can be elided.
In future, it may be possible to avoid some of this masking by applying
path-clipping algorithms (but that's fairly tricky, and normally
requires stronger guarantees about paths than we currently have).
The methods try_release_clean_pages() and release_all_clean_pages() in
InodeVMObject are almost identical. This commit makes them both use the
same code path.