All of this error propogation came from a single call to
HashMap::try_ensure_capacity! As part of the ongoing effort to ignore
small allocation failures, lets just assert this works. This has the
nice side-effect of propogating out to a few other classes.
We had previous implemented some plumbing for file input elements in
commit 636602a54e.
This implements the return path for chromes to inform WebContent of the
file(s) the user selected. This patch includes a dummy implementation
for headless-browser to enable testing.
When a tab or nested traversable navigable is closed, there might be
messages still in the pipe from the UI process that we need to
gracefully drop, rather than crash trying to access an invalid pointer.
The IPC layer between chromes and LibWeb now understands that multiple
top level traversables can live in each WebContent process.
This largely mechanical change adds a billion page_id/page_index
arguments to make sure that pages that end up opening new WebViews
through mechanisms like window.open() still work properly with those
extra windows.
When the WebContent process has painted to its shared bitmaps, it sends
a synchronous IPC to the browser process to let the chrome paint. It is
synchronous to ensure the WC process doesn't paint onto the backing
bitmap again while it is being displayed.
However, this can cause a crash at exit if the browser process quits
while the WC process is waiting for a response to this IPC.
This patch makes the painting logic asynchronous by letting the browser
process broadcast when it has finished handling the paint IPC. The WC
process will not paint anything again until it receives that message. If
it had tried to repaint while waiting for that message, that paint will
be deferred until it arrives.
These IPCs are different than other IPCs in that we can't just set up a
callback function to be invoked when WebContent sends us the screenshot
data. There are multiple places that would set that callback, and they
would step on each other's toes.
Instead, the screenshot APIs on ViewImplementation now return a Promise
which callers can interact with to receive the screenshot (or an error).
All DOM node mutation IPCs now invoke an async completion IPC after the
DOM is mutated. This allows consolidating where the Inspector updates
its view and the selected DOM node.
This also allows improving the response to removing a DOM node. We would
previously just select the <body> tag after removing a DOM node because
the Inspector client had no idea what node preceded the removed node.
Now the WebContent process can just indicate what that node is. So now
after removing a DOM node, we inspect either its previous sibling (if it
had one) or its parent.
Rename them from "did_get_*" to "did_inspect_*", to correspond to the
request methods "inspect_dom_tree" and "inspect_accessibility_tree". No
functional change, but this makes it a bit easier to stare at IPC files
side-by-side and know which response method corresponds to a request
method at a quick glance.
With this change, chrome no longer has to ask the WebContent process
to paint the next frame into a specified bitmap. Instead, it allocates
bitmaps and sends them to WebContent, which then lets chrome know when
the painting is done.
This work is a preparation to move the execution of painting commands
into a separate thread. Now, it is much easier to start working on the
next frame while the current one is still rendering. This is because
WebContent does not have to inform chrome that the current frame is
ready before it can request the next frame.
Additionally, as a side bonus, we can now eliminate the
did_invalidate_content_rect and did_change_selection IPC calls. These
were used solely for the purpose of informing chrome that it needed to
request a repaint.
This commit un-deprecates DeprecatedString, and repurposes it as a byte
string.
As the null state has already been removed, there are no other
particularly hairy blockers in repurposing this type as a byte string
(what it _really_ is).
This commit is auto-generated:
$ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \
Meta Ports Ladybird Tests Kernel)
$ perl -pie 's/\bDeprecatedString\b/ByteString/g;
s/deprecated_string/byte_string/g' $xs
$ clang-format --style=file -i \
$(git diff --name-only | grep \.cpp\|\.h)
$ gn format $(git ls-files '*.gn' '*.gni')
No functional impact intended. This is just a more complicated way of
writing what we have now.
The goal of this commit is so that we are able to store the 'name' of a
pseudo element for use in serializing 'unknown -webkit-
pseudo-elements', see:
https://www.w3.org/TR/selectors-4/#compat
This is quite awkward, as in pretty much all cases just the selector
type enum is enough, but we will need to cache the name for serializing
these unknown selectors. I can't figure out any reason why we would need
this name anywhere else in the engine, so pretty much everywhere is
still just passing around this raw enum. But this change will allow us
to easily store the name inside of this new struct for when it is needed
for serialization, once those webkit unknown elements are supported by
our engine.
The empty value we are currently returning hits the `decltype(nullptr)`
constructor of TakeDocumentScreenshotResponse. This is interpreted as an
invalid response by LibIPC. Instead, return a Gfx::ShareableBitmap that
the client-side can handle, and e.g. display an error, rather than the
message just being dropped.
Currently, when editing a DOM attribute, the replacement method first
removes the attribute, then adds the replacement attributes. This
results in the edited attribute jumping to the end of the attribute
list in the Inspector.
This patch will try to avoid removing the attribute if one of the
replacements has the same name. This will keep the edited attribute in
the same location.
The FIXME added to ConnectionFromClient::remove_dom_node is copied from
Web::EditEventHandler. The same behavior is observed here, with many
lingering Layout::TextNodes, for example.
This adds APIs to allow Ispector clients to:
* Change a DOM text or comment node's text data.
* Add, replace, or remove a DOM element's attribute.
* Change a DOM element's tag.
In order for same-origin NavigableContainers (iframe, frame, embed, ...)
and window.open() WindowProxies to have the proper JS access to their
embedder/opener, we need to host multiple top level traversables in the
same WebContent process. As a first step, make WebContent::PageHost hold
a HashMap of PageClient objects, each holding their own Web::Page that
represents a TraversableNavigable's API surface with the UI process.
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.
The old name was pretty confusing, since it had nothing to do with the
common "id" content attribute.
This makes way for using id() to return the "id" attribute instead. :^)
Renaming the DeprecatedString version of this function to
Element::get_deprecated_attribute.
While performing this rename, port over functions where it is trivial to
do so to the Optional<String> version of this function.
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()`).
Fixes regression introduced in b4fe118dff
The `WebContentConsoleClient` needs to be created not just once, but
for every new document. Although the JS Console window allows
communication only with the active document associated with the
top-level browsing context, we still need a console client for each
iframe's document to ensure their console logs are printed.
In the future, we might consider adding the ability to switch which
document the JS Console window communicates with.
Fixes https://github.com/SerenityOS/serenity/issues/21117
This attempts to load the URL of the first `<link rel="match" href=""/>`
it finds. If that tag is missing, we load an error page to make sure
the ref-test fails. (And to provide some feedback if someone looks at
the screenshot somehow.) Wrong URLs will instead end up loading the
default 404 error page.
Before page_did_create_main_document() only initialized ConsoleClient
for top-level browsing context which means that nested browsing context
could not print into the console.
With this change, ConsoleClient is initialized for documents created
for nested browsing context too. One ConsoleClient is shared between
all browsing contexts within the same page.
