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.
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 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.
