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.
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.
We will be asked for different highlighters throughout the DevTools
session, e.g. ViewportSizeOnResizeHighlighter and BoxModelHighlighter.
The latter will be responsible for rendering and overlay on DOM nodes
when the user hovers over a node in the inspector panel.
This removes the use of StringBuilder::OutputType (which was ByteString,
and only used by the JSON classes). And it removes the StringBuilder
template parameter from the serialization methods; this was only ever
used with StringBuilder, so a template is pretty overkill here.
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.
Previously, we could connect to our DevTools server from Firefox, but
could not see any information on Ladybird's opened tabs. This implements
enough of the protocol to see a tab list, but we cannot yet inspect the
tabs.
To aid with debugging web page issues in Ladybird without needing to
implement a fully fledged inspector, we can implement the Firefox
DevTools protocol and use their DevTools. The protocol is described
here:
https://firefox-source-docs.mozilla.org/devtools/backend/protocol.html
This commit contains just enough to connect to Ladybird from a DevTools
client.
