Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-24 01:53:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibDevTools/Actors/HighlighterActor.cpp

69 lines
2 KiB
C++
Raw Normal View History

LibDevTools: Implement enough of the protocol to inspect tabs 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.
2025-02-15 07:57:36 -05:00
/*
* Copyright (c) 2025, Tim Flynn <trflynn89@ladybird.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <AK/JsonObject.h>
#include <LibDevTools/Actors/HighlighterActor.h>
LibDevTools: Support highlighting DOM nodes hovered in the inspector
2025-02-20 08:58:35 -05:00
#include <LibDevTools/Actors/InspectorActor.h>
#include <LibDevTools/Actors/TabActor.h>
#include <LibDevTools/Actors/WalkerActor.h>
#include <LibDevTools/DevToolsDelegate.h>
#include <LibDevTools/DevToolsServer.h>
LibDevTools: Implement enough of the protocol to inspect tabs 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.
2025-02-15 07:57:36 -05:00
namespace DevTools {
LibDevTools: Support highlighting DOM nodes hovered in the inspector
2025-02-20 08:58:35 -05:00
NonnullRefPtr<HighlighterActor> HighlighterActor::create(DevToolsServer& devtools, String name, WeakPtr<InspectorActor> inspector)
LibDevTools: Implement enough of the protocol to inspect tabs 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.
2025-02-15 07:57:36 -05:00
{
LibDevTools: Support highlighting DOM nodes hovered in the inspector
2025-02-20 08:58:35 -05:00
return adopt_ref(*new HighlighterActor(devtools, move(name), move(inspector)));
LibDevTools: Implement enough of the protocol to inspect tabs 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.
2025-02-15 07:57:36 -05:00
}
LibDevTools: Support highlighting DOM nodes hovered in the inspector
2025-02-20 08:58:35 -05:00
HighlighterActor::HighlighterActor(DevToolsServer& devtools, String name, WeakPtr<InspectorActor> inspector)
LibDevTools: Implement enough of the protocol to inspect tabs 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.
2025-02-15 07:57:36 -05:00
: Actor(devtools, move(name))
LibDevTools: Support highlighting DOM nodes hovered in the inspector
2025-02-20 08:58:35 -05:00
, m_inspector(move(inspector))
LibDevTools: Implement enough of the protocol to inspect tabs 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.
2025-02-15 07:57:36 -05:00
{
}
HighlighterActor::~HighlighterActor() = default;
LibDevTools: Support highlighting DOM nodes hovered in the inspector
2025-02-20 08:58:35 -05:00
void HighlighterActor::handle_message(StringView type, JsonObject const& message)
LibDevTools: Implement enough of the protocol to inspect tabs 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.
2025-02-15 07:57:36 -05:00
{
JsonObject response;
if (type == "show"sv) {
LibDevTools: Add a helper to acquire required message parameters 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.
2025-03-11 09:05:01 -04:00
auto node = get_required_parameter<String>(message, "node"sv);
if (!node.has_value())
LibDevTools: Support highlighting DOM nodes hovered in the inspector
2025-02-20 08:58:35 -05:00
return;
response.set("value"sv, false);
LibDevTools: Add a helper to extract a DOM node JSON object more easily 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); }
2025-03-05 16:16:49 -05:00
if (auto dom_node = WalkerActor::dom_node_for(InspectorActor::walker_for(m_inspector), *node); dom_node.has_value()) {
LibDevTools: Associate node actors with a DOM node identifier 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.
2025-03-06 19:49:27 -05:00
devtools().delegate().highlight_dom_node(dom_node->tab->description(), dom_node->identifier.id, dom_node->identifier.pseudo_element);
LibDevTools: Add a helper to extract a DOM node JSON object more easily 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); }
2025-03-05 16:16:49 -05:00
response.set("value"sv, true);
LibDevTools: Support highlighting DOM nodes hovered in the inspector
2025-02-20 08:58:35 -05:00
}
LibDevTools: Implement enough of the protocol to inspect tabs 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.
2025-02-15 07:57:36 -05:00
send_message(move(response));
return;
}
if (type == "hide"sv) {
LibDevTools: Support highlighting DOM nodes hovered in the inspector
2025-02-20 08:58:35 -05:00
if (auto tab = InspectorActor::tab_for(m_inspector))
devtools().delegate().clear_highlighted_dom_node(tab->description());
LibDevTools: Implement enough of the protocol to inspect tabs 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.
2025-02-15 07:57:36 -05:00
send_message(move(response));
return;
}
send_unrecognized_packet_type_error(type);
}
JsonValue HighlighterActor::serialize_highlighter() const
{
JsonObject highlighter;
highlighter.set("actor"sv, name());
return highlighter;
}
}
Reference in a new issue Copy permalink