These commands are used for the "Edit As HTML" feature in DevTools. This
renames our existing HTML getter IPC to indicate that it is for outer
HTML. DevTools will need a separate inner HTML getter.
Since cross-site navigation is a pretty frequent task, creating a spare
process is commonplace in other browsers to reduce the overhead of
directing the target site to a new process.
We store this process on the WebView application. If it is unavailable,
we queue a task to create it later.
Site isolation is a common technique to reduce the chance that malicious
sites can access data from other sites. When the user navigates, we now
check if the target site is the same as the current site. If not, we
instruct the UI to perform the navigation in a new WebContent process.
The phrase "site" here is defined as the public suffix of the URL plus
one level. This means that navigating from "www.example.com" to
"sub.example.com" remains in the same process.
There's plenty of room for optimization around this. For example, we can
create a spare WebContent process ahead of time to hot-swap the target
site. We can also create a policy to keep the navigated-from process
around, in case the user quickly navigates back.
This has been a longstanding ergonomic issue with our IPC compiler. Non-
trivial types were previously passed by const&. So if we wanted to avoid
expensive copies, we would have to const_cast and move the data.
We now pass ownership of all transferred data to the client subclasses.
This allows us to remove const_cast from these methods, and allows us to
avoid some trivial expensive copies that we didn't bother to const_cast.
This requires a couple of amendments to the DOM node serialization.
Namely, we need to include the HTML namespace, otherwise the context
menu item to create a new node is disabled.
Trivia is whatever whitespace and comments appear before a token.
Previously this was always given a TokenCategory of Invalid, so it
would be displayed as an error in the view-source page, with red wiggly
underlines. Instead, treat it as what it actually is: whitespace and
comments!
The "on_received_console_message" and "on_received_console_messages"
were indistinguishable in purpose based on their name. This renames them
to:
on_console_message_available - WebContent has output a console message
and it is available for the client to retrieve.
on_received_styled_console_messages - WebContent has replied to a
request for the available console messages.
The "styled" qualifier is used here to indicate that the messages have
been styled with CSS for display in a WebView. This is to prepare for
an upcoming patch where DevToolsConsoleClient will not stylize the
output; DevTools will want the raw JS values.
The `cursor` property accepts a list of possible cursors, which behave
as a fallback: We use whichever cursor is the first available one. This
is a little complicated because initially, any remote images have not
loaded, so we need to use the fallback standard cursor, and then switch
to another when it loads.
So, ComputedValues stores a Vector of cursors, and then in EventHandler
we scan down that list until we find a cursor that's ready for use.
The spec defines cursors as being `<url>`, but allows for `<image>`
instead. That includes functions like `linear-gradient()`.
This commit implements image cursors in the Qt UI, but not AppKit.
This supports evaluating the script and replying with the result. We
currently serialize JS objects to a string, but we will need to support
dynamic interaction with the objects over IPC. This does not yet support
sending console messages to DevTools.
Our existing WebContentConsoleClient is very specific to our home-grown
Inspector. It renders console output to an HTML string. For DevTools, we
will not want this behavior; we will want to send representations of raw
JS values.
This patch makes WebContentConsoleClient a base class to handle console
input from the user, either from the Inspector or from DevTools. It then
moves the HTML rendering needed for the Inspector to a new class,
InspectorConsoleClient. And we add a DevToolsConsoleClient (currently
just stubbed) to handle needs specific to DevTools.
We choose at runtime which console client to install, based on the
--devtools command line flag.
LibDevTools was implicitly including generated IPC endpoints from
LibWebView. This is not a dependency declared in the CMakeLists.txt. So
updates to the IPC file might not have caused the endpoint header to be
regenerated by the time LibDevTools is compiled, resulting in a build
error.
This patch removes that implicit dependency entirely.
Our own Inspector differs from most other DevTools implementations with
regard to highlighting DOM nodes as you hover elements in the inspected
DOM tree. In other implementations, as you change the hovered node, the
browser will render a box model overlay onto the page for that node. We
currently don't do this; we wait until you click the node, at which
point we both paint the overlay and inspect the node's properties.
This patch does not change that behavior, but separates the IPCs and
internal tracking of inspected nodes to support the standard DevTools
behavior. So the DOM document now stores an inspected node and a
highlighted node. The former is used for features such as "$0" in the
JavaScript console, and the latter is used for the box model overlay.
Our Inspector continues to set these to the same node.
We currently receive serialized JSON values over IPC and forward them to
them WebView callbacks, leaving it to the implementations of those
callbacks to parse the strings as JSON objects. This patch hoists that
parsing up to WebContentClient as soon as the IPC message is received.
This is to reduce the work needed for secondary implementations of these
callbacks (i.e. our Firefox DevTools server).
This adds a command line option to enable the DevTools server. Here, we
make the application the DevToolsDelegate to reply to requests from the
DevTools server about the state of the application.
For Firefox DevTools, we will need to track WebViews by a numerical ID.
Here, we just increment a static 64-bit counter. We can switch to using
IDAllocator if we ever have an issue with this.
This patch adds such an ID to the views and a couple of APIs to access
WebViews after creation.
The previous code to determine the SourceDocument's lines was too naive:
the source text can contain other newline characters and sequences, and
the HTML/CSS/JS syntax highlighters would take those into account when
determining what line a token is on. This disagreement would cause
incorrect highlighting, or even crashes, if the source didn't solely use
`\n` for its newlines.
In order to have everyone agree on what a line is, this patch first
processes the source to replace all newlines with `\n`. The need to
copy the source like this is unfortunate, but viewing the source is a
rare enough action that this should not cause any noticeable
performance problems.
As the callers have a String, and we want a String, this also changes
the function parameters to keep the source as a String instead of
converting it to StringView and back.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/3169
If Ctrl is pressed when a string is entered into the location bar and
that string doesn't contain a valid TLD, ".com" is added to that string.
Previously, only a small, fixed set of TLDs was checked. We now use the
public suffix list to determine if the given address contains a valid
TLD.
