This change solves a crash where it was possible that the
"Color Masking" could try to access pixel coordinates that where beyond
the boundaries of the image.
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.
Ran into a crash here while testing LibProtocol changes. The method we
invoke here (did_progress) already accepts an Optional, and handles when
that Optional is empty. So there's no need to assume `total_size` is
non-empty.
LibWeb will need to use unbuffered requests to support server-sent
events. Connection for such events remain open and the remote end sends
data as HTTP bodies at its leisure. The browser needs to be able to
handle this data as it arrives, as the request essentially never
finishes.
To support this, this make Protocol::Request operate in one of two
modes: buffered or unbuffered. The existing mechanism for setting up a
buffered request was a bit awkward; you had to set specific callbacks,
but be sure not to set some others, and then set a flag. The new
mechanism is to set the mode and the callbacks that the mode needs in
one API.
This is to avoid including any LibProtocol header in Objective-C source
files, which will cause a conflict between the Protocol namespace and a
@Protocol interface.
See Ladybird/AppKit/Application/ApplicationBridge.cpp for why this
conflict unfortunately cannot be worked around.
To align the cursor theme tab to how DisplaySettings themes tab works,
this change forces the theme combo box to not allow free-text. Currently
on a click it puts the text cursor in the box to allow typing anything
rather than acting as a dropdown when clicking anywhere on the field.
Fixes#24306
We can now tell the difference between an own property access and a
subsequent (automatic) prototype chain access.
This will be used to implement caching of prototype chain accesses.
Now that the chrome process is a singleton on all platforms, we can
safely add a cache to the CookieJar to greatly speed up access. The way
this works is we read all cookies upfront from the database. As cookies
are updated by the web, we store a list of "dirty" cookies that need to
be flushed to the database. We do that synchronization every 30 seconds
and at shutdown.
There's plenty of room for improvement here, some of which is marked
with FIXMEs in the CookieJar.
Before these changes, in a SQL database populated with 300 cookies,
browsing to https://twinings.co.uk/ WebContent spent:
19,806ms waiting for a get-cookie response
505ms waiting for a set-cookie response
With these changes, it spends:
24ms waiting for a get-cookie response
15ms waiting for a set-cookie response
When we try to start a long-running child process (e.g. a GUI app)
using a combination of the POSIX spawn and waitpid API, the Run
process ends up waiting for it to end before making any changes
to the path history. This leads to some confusion when trying to
fire up another Run process only to see that it did not save the
path to this program.
This PR resolves this by saving the path after it was created using
the POSIX spawn API.
'set_frame_style' is what Frame itself uses to set the value, and a
significant number of GML files use 'frame_style' instead of just
'style', so let's switch to it and use it everywhere consistently.
This partially supports the WebView::ChromeProcess mechanics. New
windows aren't totally supported and will just open a new tab for now.
When launched via the Browser's AppFile (either through quick launch or
the desktop shortcut), a new window will be requested.
Most of these now just await the image decoding, equivalent (ish) to
the old behavior. A more async-aware refactor should happen some time
in the future.
These changes are compatible with clang-format 16 and will be mandatory
when we eventually bump clang-format version. So, since there are no
real downsides, let's commit them now.
The previous name was extremely misleading, because the call is used for
pushing or replacing new session history entry on chrome side instead of
only changing URL.
Currently the `<select>` dropdown IPC uses the option value attr to
find which option is selected. This won't work when options don't
have values or when multiple options have the same value. Also the
`SelectItem` contained so weird recursive structures that are
impossible to create with HTML. So I refactored `SelectItem` as a
variant, and gave the options a unique id. The id is send back to
`HTMLSelectElement` so it can find out exactly which option element
is selected.
