We previously only supported enabling headless mode on a per-session
basis via the capabilities record. We don't have the ability to mutate
this record from WPT, so this adds a flag to set the default mode.
Now that we use libcurl, there's no reason to keep Qt networking around.
Further, it doesn't support all features we need anyways, such as non-
buffered request handling for SSE.
Using Qt networking when running web platform tests improves
performance significantly. The time to run the subset of tests we run
on CI drops from 21.9 seconds to 8.2 seconds on my machine.
This commit un-deprecates DeprecatedString, and repurposes it as a byte
string.
As the null state has already been removed, there are no other
particularly hairy blockers in repurposing this type as a byte string
(what it _really_ is).
This commit is auto-generated:
$ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \
Meta Ports Ladybird Tests Kernel)
$ perl -pie 's/\bDeprecatedString\b/ByteString/g;
s/deprecated_string/byte_string/g' $xs
$ clang-format --style=file -i \
$(git diff --name-only | grep \.cpp\|\.h)
$ gn format $(git ls-files '*.gn' '*.gni')
We already do this for headless-browser. There's no need to open any URL
other than about:blank when starting a WebDriver session. We should also
do this from WebDriver code, rather than in special logic in Browser's
main.cpp.
This will help a lot with developing chromes for different UI frameworks
where we can see which helper classes and processes are really using Qt
vs just using it to get at helper data.
As a bonus, remove Qt dependency from WebDriver.
We were super inconsistent about this, with most "new" classes living in
the Ladybird namespace, while "old" ones were in the global namespace,
or even sitting in the Browser namespace.
headless-browser currently uses its own PageClient to load web pages
in-process. Due to this, it also needs to set up a whole bunch of other
objects needed to run LibWeb, e.g. image decoders, request servers, etc.
This changes headless-browser to instead implement a WebView to launch
WebContent out-of-process. This implementation is almost entirely empty,
but can be filled in as-needed. For example, we may want to print
JavaScript console messages.
This allows the WebDriver to take advantage of the common helper process
spawning code when launching ladybird, and to not assume a particular
directory layout.
This allows us to use standard Serenity IPC infrastructure rather than
manually creating FD-passing sockets. This also lets us use Serenity's
WebDriver Session class, removing the copy previously used in Ladybird.
This ensures any changes to Session in the future will be picked up by
Ladybird for free.
This adds a WebDriver binary for Ladybird to make use of Serenity's
WebDriver implementation. This has to use the same IPC socket handling
that was used to make WebContent work out-of-process. Besides that, we
are able to reuse almost everything from Serenity.
