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>
Similar to the RequestServer, bind this from the WebContentService
implementation and have it work the same way. Deduplicate some code
while we're here.
Add a RequestServerService class that uses the LadybirdServiceBase class
added previously. Bind to it from the WebContentService's service_main()
during startup.
This will let us spawn a new process for an Android Service to handle
all our WebContent needs. The ServiceConnection is manged by each
WebView. The lifecycle of the Service is not quite clear yet, but each
bindService call will get a unique Messenger that can be used to
transfer the WebContent side of the LibIPC socketpair we use in other
ports.
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 were still missing the resources and the libraries inside the actual
bundle directory. Do it at install time to not make a mess of all the
rules. The gn build lists all the libraries in a massive list, which
is quite a pain. We can over-copy a few libraries like this to make the
install script a bit easier to follow.
We weren't installing a lot of generated sources for the top level Lagom
build or for LibWeb, making it impossible to use LibWeb from a
find_package. ...And also Kernel/API/KeyCode.h, which is included by
no less than 8 different files in Userland/Libraries. We also weren't
installing any Ladybird header files.
LibTLS still can't access many parts of the web, so let's hide this
behind a flag (with all the plumbing that entails).
Hopefully this can encourage folks to improve LibTLS's algorithm support
:^).
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.
Use a list of executables to make sure that we don't miss any of the
applications used by Ladybird and its friends like WebDriver, and make
sure to install include all executables and their runtime dependencies.
Always call platform_init after there's a QApplication, because in the
installed configuration that's how we find the resources.
Try QCoreApplication::applicationDirPath() after looking in ./WebContent
for the WebContent process. In an installed configuration, ladybird and
WebContent will both be in $PREFIX/bin.
Add install rules for WebContent and its linked libraries, for if they
ever differ from ladybird's.
This setup should allow the package maintainers who are looking to
distribute ladybird on their distributions to use CMake to install
ladybird using cmake install rules rather than having to write their own
