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.
Re-organize our helper files here a bit, to make a clearer distinction
between Qt-specific helpers and generic non-serenity helpers.
A future commit will move Lagom specific code from LibSQL to ladybird
as well, so that we can see about future generic apis for spawning
helper procesess.
We don't need the extra gradle files in our sources, the Qt CMake
integration will generate suitable ones for us.
Make sure that assets is always a folder, so that we can get the proper
layout for the ladybird-assets.tar.gz and CMake doesn't create a gzip
file with the name "assets".
Fix up the AndroidPlatform file and make sure it's linked into all the
applications that need it. Also make sure to copy all the application
shared libraries into the ladybird APK so that when we make them into
proper Services, the libs are already there.
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.
