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
:^).
The asynchronous query execution keeps causing bugs with document.cookie
so let's make the SQL database backend default off until we can trust it
to do what we need.
Things such as timers and notifiers aren't specific to one instance of
Core::EventLoop, so let's not tie them down to EventLoopImplementation.
Instead, move those APIs + signals & a few other things to a new
EventLoopManager interface. EventLoopManager also knows how to create a
new EventLoopImplementation object.
Using QEventLoop works for everything but it breaks *one* little feature
that we care about: automatically quitting the app when all windows have
been closed.
That only works if you drive the outermost main event loop with a
QCoreApplication instead of a QEventLoop. This is unfortunate, as it
complicates our API a little bit, but I'm sure we can think of a way to
make this nicer someday.
In order for QCoreApplication::exec() to process our own
ThreadEventQueue, we now have a zero-timer that we kick whenever new
events are posted to the thread queue.
This patch adds EventLoopImplementationQt which is a full replacement
for the Core::EventLoopImplementationUnix that uses Qt's event loop
as a backend instead.
This means that Core::Timer, Core::Notifier, and Core::Event delivery
are all driven by Qt primitives in the Ladybird UI and WC processes.
This adds a -P option to run Ladybird under callgrind. It starts with
instrumentation disabled. To start capturing a profile (once Ladybird
has launched) run `callgrind_control -i on` and to stop it again run
`callgrind_control -i off`.
P.s. This is pretty much stolen from Andreas (and is based on the patch
everyone [that wants a profile] have been manually applying).
Use the new get_paths_for_helper_process method in Ladybird to query
Qt for the runtime path of the current executable as well as the build
directory paths.
These changes will prevent duplication of code later when there will
also be the possibility to navigate to the homepage url as defined in
the settings on startup.
Don't use _exit() - this is a forceful exit that will bypass all exit
handlers. This includes AddressSanitizer, and will prevent ASan from
exiting the app with a fatal error code.
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.
Rather than manually launching the SQLServer process, use SQLClient's
new functionality to launch the server just once for all Ladybird
instances. Quit the SQLServer process when it no longer has any
connected clients.
This adds a SQLServer binary for Ladybird to make use of Serenity's SQL
implementation. This has to use the same IPC socket handling that was
used to make WebContent and WebDriver work out-of-process.
Unlike Serenity, Ladybird creates a new SQLServer instance for each
Ladybird instance. In the future, we should try to make sure there is
only one SQLServer instance at a time, and allow multiple Ladybird
instances to communicate with it.
The WebDriver will pass the --webdriver-fd-passing-socket command line
option when it launches Ladybird. Forward this flag onto the WebContent
process, where it will create the WebDriverConnection for IPC.
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 patch brings over the WebContent process over from SerenityOS
to Ladybird, along with a new WebContentView widget that renders
web content in a separate process.
There's a lot of jank and FIXME material here, notably I had to re-add
manually pumped Core::EventLoop instances on both sides, in order to get
the IPC protocol running. This introduces a lot of latency and we should
work towards replacing those loops with improved abstractions.
The WebContent process is built separately here (not part of Lagom) and
we provide our own main.cpp for it. Like everything, this can be better
architected, it's just a starting point. :^)
This prevents memory leaks detected by both Valgrind and ASAN/LSAN.
Valgrind is still suspicious of the leaked JS::VM from
Web::Bindings::main_thread_vm() but there's other issues with leak
checking all the GC'd objects.
Co-Authored-By: Diego Iastrubni <diegoiast@gmail.com>
This will allow us to share code with LibWebView from SerenityOS.
(This would otherwise not work, since its "WebView" namespace collides
with our "WebView" class.)
Also, we should eventually move towards a more sophisticated
multi-process WebView like OOPWV.
This patch removes the dual-event-loop setup, leaving only the Qt event
loop. We teach LibWeb how to drive Qt by installing an EventLoopPlugin.
This removes the 50ms latency on all UI interactions (and network
requests, etc.)
This patch adds an event handler to the main window which allows it to
respond to a user closing the window. This event is then passed on to
the LibCore event loop, which allows the application quit itself.
Previously the application would hang, only running in the background,
until killed by an external force.
