The inspector widget now has a new ARIA tab which displays an
individual element's ARIA properties and state. The view itself
is pretty basic for now, just being a table- there is definitely room
for some better UX here but it's enough for a first cut.
The data we want to send out of the WebContent process is identical for
audio and video elements. Rather than just duplicating all of this for
audio, generalize the names used for this IPC for all media elements.
This also encapsulates that data into a struct. This makes adding new
fields to be sent much easier (such as an upcoming field for muting the
element).
We now check if the WebContent is executable before passing it to
the valgrind wrapper. We can't rely on exec() to fail here, since it
will always succeed even when passing a bad WebContent path to valgrind.
Serenity handles this in the SystemServer already, but the simplest
place to put this logic is the ViewImplementation base class.
This is trivial to see when running Ladybird without SERENTIY_SOURCE_DIR
set, or set improperly.
This is to match Browser, where ownership of all "subwidgets" is placed
on the tab as well. This further lets us align the web view callbacks to
match Browser's OOPWV as well, which will later let us move them into
the base LibWebView class.
The implementations of handle_web_content_process_crash and
take_screenshot are exactly the same across Browser and Ladybird. Let's
reduce some code duplication and move them to LibWebView.
This allows for the browser process to control the play/pause state,
whether we paint user agent controls on the video, and whether the video
loops when it finishes playing.
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).
Currently, on Serenity, we connect to WebDriver from the browser-side of
the WebContent connection for both Browser and headless-browser.
On Lagom, we connect from within the WebContent process itself, signaled
by a command line flag.
This patch changes Lagom browsers to connect to WebDriver the same way
that Serenity browsers do. This will ensure we can do other initializers
in the same order across all platforms and browsers.
This starts moving code equally shared between the OOPWV and Ladybird
WebContentView implementations to WebView::ViewImplementation, beginning
with the client state.
