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 now create a WorkerAgent for the parent context, which is currently
only a Window. Note that Workers can have Workers per the spec.
The WorkerAgent spawns a WebWorker process to hold the actual
script execution of the Worker. This is modeled with the
DedicatedWorkerHost object in the WebWorker process.
A start_dedicated_worker IPC method in the WebWorker IPC creates the
WorkerHost object. Future different worker types may use different IPC
messages to create their WorkerHost instance.
This implementation cannot yet postMessage between the parent and the
child processes.
Co-Authored-By: Andreas Kling <kling@serenityos.org>
This template app from Android Studio should hopefully be more fun to
work on than the Qt wrapped application we were using before. :^)
It currently builds the native code using gradle rules, and has a stub
WebViewImplementationNative class that will wrap a c++ class of the same
name that inhertis from WebView::ViewImplementation. Spawning helper
processes and creating proper views in Kotlin is next on the list.
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.
