We can easily add hooks to notify the browsers of these events if any
implementation-specific handling is needed in the future, but for now,
these only repaint the client, which we can do in ViewImplementation.
Storing the backup bitmap is the same across Browser and Ladybird. Just
peform that work in LibWebView, and handle only the implementation-
specific nuances within the browsers.
This also sets the default callback to do what every non-Serenity
browser is doing, rather than copy-pasting this callback into every
implementation. The callback is still available for any platform which
might want to override the default behavior. For example, OOPWV now
overrides this callback to use FileSystemAccessClient.
The ref tests runner takes screenshots of both the input page and the
expected page, then compares them. Ref testing allows us to catch
painting bugs, which cannot be detected with the layout and text tests
we already have.
With ref tests, we'll likely want to reuse the same expectation page
for multiple inputs. Therefore, there's a `manifest.json` file that
describes the relationship between inputs and expected outputs.
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.
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
:^).
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.
WebView::ViewImplementation now remembers which JS interpreter it
started with, and uses the same setting if the WebContent process
crashes and we have to spawn a new one.
This prevents fd leaks when the user of the API forgets to pass
CloseAfterSending to IPC::File. Since we are calling leak_fd in the
constructor, we want it to also take care of closing.
On systems with the default ulimit for open files <= 256 (default
on some systems) the LibWeb tests were crashing because the
input file handles are not closed in headless-browser.
If we don't paint, SVG-as-image documents don't get laid out, and so
have 0x0 size throughout.
This change is also generally nice, as it makes the painting code run
on all the layout tests, increasing coverage. :^)
URL filtering was taking up a huge amount of time when burning through
the tests. We're not gonna have a bunch of ads to block in our local
tests, so let's just turn it off when running them.
This will make it a lot easier to understand what went wrong, especially
when the failure occurs on CI but not at home.
And of course, use LibDiff to generate the diff! :^)
Instead of starting a new headless-browser for every layout & text test,
headless-browser now gets a mode where it runs all the tests in a single
process.
This is massively faster on my machine, taking a full LibWeb test run
from 14 seconds to less than 1 second. Hopefully it will be a similarly
awesome improvement on CI where it has been soaking up more and more
time lately. :^)
The goal here is to reduce the amount of WebContent client APIs that are
duplicated across every ViewImplementation. Across our three browsers,
we currently:
Ladybird - Mix some AK::Function callbacks and Qt signals to notify
tabs of WebContent events.
Browser - Use only AK::Function callbacks.
headless-browser - Drop most events on the floor.
Instead, let's only use AK::Function callbacks across all three browsers
to propagate events to tabs. This allows us to invoke those callbacks
directly from LibWebView instead of all three browsers needing to define
a trivial `if (callback) callback();` override of a LibWebView virtual
function. For headless-browser, we can simply not set these callbacks.
As a first pass, this only converts WebContent events that are trivial
to this approach. That is, events that were simply passed onto the tab
or handled without much fuss.
This just sets up the IPC to notify the browser process of context menu
requests on video elements. The IPC contains a few pieces of information
about the state of the video element.
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).
