Move the methods to set the native/user style sheets to the base
ViewImplementation class. We must also generate the native style sheet
explicitly for now, as LibWebView on Lagom isn't able to include the
main LibWebView CMakeLists.txt file yet.
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.
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.
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 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 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.
The spec defines a Permissions Policy to control some browser behaviors
on a per-origin basis. Management of these permissions live in their own
spec: https://w3c.github.io/webappsec-permissions-policy/
This implements a somewhat ad-hoc Permissions Policy for autoplaying
media elements. We will need to implement the entire policy spec for
this to be more general.
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).
LibGUI and WebDriver (read: JSON) API boundaries use DeprecatedString,
so that is as far as these changes can reach.
The one change which isn't just a DeprecatedString to String replacement
is handling the "null" prompt response. We previously checked for the
null DeprecatedString, whereas we now represent this as an empty
Optional<String>.
This starts moving code equally shared between the OOPWV and Ladybird
WebContentView implementations to WebView::ViewImplementation, beginning
with the client state.
By setting this hint, you indicate to OOPWV that the content inside will
scale itself to the viewport size. In such situations, it's fine for
OOPWV to reuse a scaled version of an outdated backing store while the
view is being resized.
This patch also stubs out notify_server_did_get_accessiblity_tree in
ladybird since ViewImplementation now has it. However, this feature
is still immature, so just stubbing out in ladybird for now. Once we
have more robust support in Serenity (namely ARIA properties/state
and accessible names and descriptions) we can port this
functionality over.
This fixes a few things I noticed whilst working on the inspector
for Ladybird.
1.
The computed and resolved values were being passed swapped around
from the inspect_dom_node() IPC call. I.e. computed values were
passed as resolved values and vice versa. This was then fixed by
swapping them again in the InspectorWidget (two errors canceled out).
2.
Resolved values were called "specified values" seemingly only in the
inspect_dom_node() IPC calls. This was a little confusing so I've
renamed them to back to "resolved values" for consistency.
3.
The inspector took and stored the DOM JSON strings unnecessarily,
all the models immediately parse the JSON and don't need the strings
to hang around.
This currently doesn't work when running Serenity through QEMU, as it
doesn't pass the side button events over to Serenity due to some bug or
missing feature.
Updating cookies through these hooks happens in one of two manners:
1. Through the Browser's storage inspector.
2. Through WebDriver's delete-cookies operation.
In (1), we should not restrict ourselves to being able to delete cookies
for the current page. For example, it's handy to open the inspector from
the welcome page and be able to delete cookies for any domain.
In (2), we already are only interacting with cookies that have been
matched against the document URL.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
We now replace the current history entry if the page-load has been
caused because of a redirect. This makes it able to traverse the
history if one of the entries redirects you, which previously
caused an infinite history traversion loop.
