This is an internal object that must be explicitly enabled by the chrome
before it is added to the Window. The Inspector object will be used by a
special WebView that will replace all chrome-specific inspector windows.
The IDL defines methods that this WebView will need to inform the chrome
of various events, such as the user clicking a DOM node.
This commit introduces 3 things:
- Support for the color type in HTMLInputElement itself
- A mechanism for handling non event loop blocking dialogs in Page
- The associated plumbing up to ViewImplementation
Frontends may add support for the color picker with the
ViewImplementation.on_request_color_picker function
After moving to navigables, we started reusing the code that populates
session history entries with the srcdoc attribute value from iframes
in `Page::load_html()` for loading HTML.
This change addresses a crash in `determine_the_origin` which occurred
because this method expected the URL to be `about:srcdoc` if we also
provided HTML content (previously, it was the URL passed along with the
HTML content into `load_html()`).
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.
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.
In order to follow spec text to achieve this, we need to change the
underlying representation of a host in AK::URL to deserialized format.
Before this, we were parsing the host and then immediately serializing
it again.
Making that change resulted in a whole bunch of fallout.
After this change, callers can access the serialized data through
this concept-host-serializer. The functional end result of this
change is that IPv6 hosts are now correctly serialized to be
surrounded with '[' and ']'.
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 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.
