This implements a stub ElementInternals object which implements the
shadowRoot getter only.
Also implement attachInternals function.
(cherry picked from commit a65f1ecc375fa02deeab5d0e7ab4702972ffa72e)
8263e0a619 added `-Wno-coroutine-missing-unhandled-exception` to the
cmake build, and the coroutine code does not build without it.
Unbreaks building e.g. `js` with GN.
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.)
For some reason, WebContent fails to load simple sites like xkcd.com
without the Qt event loop, even when using RequestServer instead of the
Qt networking stack. The CMake build on Linux has the same issue if we
skip installing the Qt event loop. It's not clear why this is - whether
something depends on the Qt event loop, or if there's a bug in the Unix
event loop implementation.
This is, however, also needed to use the --enable-qt-networking feature.
EventSource allows opening a persistent HTTP connection to a server over
which events are continuously streamed.
Unfortunately, our test infrastructure does not allow for automating any
tests of this feature yet. It only works with HTTP connections.
Supporting unbuffered fetches is actually part of the fetch spec in its
HTTP-network-fetch algorithm. We had previously implemented this method
in a very ad-hoc manner as a simple wrapper around ResourceLoader. This
is still the case, but we now implement a good amount of these steps
according to spec, using ResourceLoader's unbuffered API. The response
data is forwarded through to the fetch response using streams.
This will eventually let us remove the use of ResourceLoader's buffered
API, as all responses should just be streamed this way. The streams spec
then supplies ways to wait for completion, thus allowing fully buffered
responses. However, we have more work to do to make the other parts of
our fetch implementation (namely, Body::fully_read) use streams before
we can do this.
The logic in this script was *intended* to use the system's default
compiler if it was sufficiently new, and only start searching for the
latest installed if the default was not suitable.
However, the `cxx` program does not exist on Unixes, so the version
check always failed. We should be using the standard `c++` program name
instead.
After this change, the `CC` and `CXX` environment variables will have to
be used if someone wants to force a newer compiler version.
No behavior change. No measurable performance different either.
(I tried `hyperfine 'Build/lagom/bin/image --no-output foo.webp'`
for a few input images before and after this change, and I didn't
see a difference. I also tried if moving both
Gfx::CanonicalCode::read_symbol() and
Compress::CanonicalCode::read_symbol() inline, and that didn't
help either.)
* Matches how the loader is organized
* `compress_VP8L_image_data()` will grow longer when we add actual
compression
* Maybe someone wants to write a lossy compressor one day
No behavior change.
Nobody uses this functionality. I used this code on my old 2007 ICH7
test machine about a year ago, but bare metal is a small aspect of the
project, so it's safe to assume that nobody really tests this piece of
code.
Therefore, let's drop this for good and focus on more modern hardware.
Xcode clang doesn't understand the -std=c++23 spelling yet, and this
is what CMake's `set(CMAKE_CXX_STANDARD 23)` translates to too.
Unbreaks building with Xcode clang on macOS.
This allows main UI processes created while there is a currently
running one to request a new tab or a new window with the initial urls
provided on the command line. This matches (almost) the behavior of
Chromium and Firefox.
Add a new IPC protocol between two UI processes. The main UI process
will create an IPC server socket, while secondary UI processes will
connect to that socket and send over the URLs and action it wants the
main process to take.
It previously resided in LibWebView to hide the details of launching a
singleton process. That functionality now lives in LibCore. By moving
this to Ladybird, we will be able to register the process with the task
manager.
This just moves the code to launch a single process such as SQLServer to
LibCore. This will allow re-using this feature for other processes, and
will allow moving the launching of SQLServer to Ladybird.
