The NodeIdentifier struct essentially contains the DOM node ID within
its WebContent process. These will repeat across multiple processes,
thus we cannot use them to search for node actors in the global actor
registry.
Instead, we can store a map of all node actors created by the walker
itself. The NodeIdentifier is then appropriate for actor lookups on
that map. This has the added benefit of not needing to search the entire
actor registry many times while forming the DOM node caches.
This fix allows us to inspect multiple tabs at once.
We must reply to requests received from the client in the order they are
received. The wrench in this requirement is handling requests that must
be performed asynchronously, such as fetching the serialized DOM tree
from the WebContent process.
We currently handle this with a "block token". Async request handlers
hold a token that blocks any subsequent responses from being sent. When
that token is removed (i.e. the async request now has a response to be
sent), the async response is then sent followed by the blocked responses
in-order.
This strategy had a limitation that we could not handle an actor trying
to take 2 block tokens, meaning only one async request could be handled
at a time. This has been fine so far, but an upcoming feature (style
sheet sources) will break this limitation. The client will request N
sources at a time, which would try to take N block tokens.
The new strategy is to assign all requests an ID, and store a list of
request IDs that are awaiting a response. When the server wants to send
a reply, we match the ID of the replied-to message to this list of IDs.
If it is not the first in this list, then we are blocked waiting for an
earlier reply, and just store the response. When the earlier request(s)
receive their response, we can then send out all blocked replies (up to
the next request that has not yet received a response).
This is to prepare for an upcoming change where we will need to track
replies to messages by ID. We will be able to add parameters to this
structure without having to edit every single actor subclass header
file.
This removes some boilerplate around executing async requests, such as
calling dbgln_if on any errors, handling weak pointers to `this`, and
dealing with block tokens.
This is just to help make the message handlers a bit briefer. I had
considered adding a TRY-like macro to auto-return when the lookup fails,
but since statement expressions cannot return references, that would
result in a copy of all e.g. object and array lookups.
The "from" field is required in every response. It is the name of the
actor sending the message. This patch fills in the "from" field in the
Actor base class so that subclasses don't have to.
DevTools will ask us to find nodes by their actor names. If the actor is
missing, we should inform DevTools of the error instead of just dropping
the request.
The diff here is a bit noisy, just due to a leftward shift of code that
used to be in an if-statement.
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.
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.
This is a prepatory commit to be able to handle DOM mutations. Once a
node actor is created, the DOM node it is created for must continue to
be associated with the same actor even after DOM mutations. This change
stores an identifier on the node actor, and only creates new actors when
an actor for a node does not exist.
The pattern of:
auto tab = get_tab();
auto walker = get_walker();
if (tab && walker) {
if (auto node = walker->dom_node(node_id)) {
delegate().do_something(tab->description(), node);
}
}
Is getting a bit unergonomic and is often repeated. This patch just adds
a helper to WalkerActor to do most of this work, so now we have:
if (auto node = WalkerActor::dom_node_for(get_walker(), node_id)) {
delegate().do_something(node->tab->description(), node);
}
The DevTools client will ask for this actor before trying to render any
box model or computed style information. We can just stub out this actor
for now.
The DevTools client will now send requests to the node actor, rather
than just sending messages to other actors on the node's behalf.
This exposed a slight issue in the way we assign actor IDs. Node actors
are created in the walker actor constructor, which executes before the
actor ID is incremented. So we must be sure to increment the actor ID
before invoking any actor constructors. Otherwise, the walker actor and
the first node actor have the same numeric ID.
There is a lot needed all at once to actually inspect a tab's DOM tree.
It begins with requesting a "watcher" from a TabActor. It seems there
can be many types of watchers, but here we implement the "frame" watcher
only. The watcher creates an "inspector", which in turn creates a
"walker", which is the actor ultimately responsible for serializing and
inspecting the DOM tree.
In between all that, the DevTools client will send a handful of other
informational requests. If we do not reply to these, the client will not
move forward with the walker. For example, the CSSPropertiesActor will
be asked for a list of all known CSS properties.
