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

124 lines
3.9 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/Debug.h>
#include <AK/JsonObject.h>
#include <LibDevTools/Actors/HighlighterActor.h>
#include <LibDevTools/Actors/InspectorActor.h>
#include <LibDevTools/Actors/PageStyleActor.h>
#include <LibDevTools/Actors/TabActor.h>
#include <LibDevTools/Actors/WalkerActor.h>
#include <LibDevTools/DevToolsDelegate.h>
#include <LibDevTools/DevToolsServer.h>
namespace DevTools {
LibDevTools+LibWebView: Port DevTools to String
2025-02-19 09:28:02 -05:00
NonnullRefPtr<InspectorActor> InspectorActor::create(DevToolsServer& devtools, String name, WeakPtr<TabActor> tab)
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
{
return adopt_ref(*new InspectorActor(devtools, move(name), move(tab)));
}
LibDevTools+LibWebView: Port DevTools to String
2025-02-19 09:28:02 -05:00
InspectorActor::InspectorActor(DevToolsServer& devtools, String name, WeakPtr<TabActor> tab)
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))
, m_tab(move(tab))
{
}
InspectorActor::~InspectorActor() = default;
LibDevTools: Store highlighter actors by type 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.
2025-02-20 08:38:58 -05:00
void InspectorActor::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;
response.set("from"sv, name());
if (type == "getPageStyle"sv) {
if (!m_page_style)
m_page_style = devtools().register_actor<PageStyleActor>();
response.set("pageStyle"sv, m_page_style->serialize_style());
send_message(move(response));
return;
}
if (type == "getHighlighterByType"sv) {
LibDevTools: Store highlighter actors by type 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.
2025-02-20 08:38:58 -05:00
auto type_name = message.get_string("typeName"sv);
if (!type_name.has_value()) {
send_missing_parameter_error("typeName"sv);
return;
}
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: Store highlighter actors by type 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.
2025-02-20 08:38:58 -05:00
auto highlighter = m_highlighters.ensure(*type_name, [&]() -> NonnullRefPtr<HighlighterActor> {
LibDevTools: Support highlighting DOM nodes hovered in the inspector
2025-02-20 08:58:35 -05:00
return devtools().register_actor<HighlighterActor>(*this);
LibDevTools: Store highlighter actors by type 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.
2025-02-20 08:38:58 -05:00
});
response.set("highlighter"sv, highlighter->serialize_highlighter());
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 == "getWalker"sv) {
if (auto tab = m_tab.strong_ref()) {
auto block_token = block_responses();
devtools().delegate().inspect_tab(tab->description(),
[weak_self = make_weak_ptr<InspectorActor>(), block_token = move(block_token)](ErrorOr<JsonValue> dom_tree) mutable {
if (dom_tree.is_error()) {
dbgln_if(DEVTOOLS_DEBUG, "Unable to retrieve DOM tree: {}", dom_tree.error());
return;
}
if (!WalkerActor::is_suitable_for_dom_inspection(dom_tree.value())) {
dbgln_if(DEVTOOLS_DEBUG, "Did not receive a suitable DOM tree: {}", dom_tree);
return;
}
if (auto self = weak_self.strong_ref())
self->received_dom_tree(move(dom_tree.release_value().as_object()), move(block_token));
});
}
return;
}
LibDevTools: Support highlighting DOM nodes hovered in the inspector
2025-02-20 08:58:35 -05:00
if (type == "supportsHighlighters"sv) {
response.set("value"sv, true);
send_message(move(response));
return;
}
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_unrecognized_packet_type_error(type);
}
void InspectorActor::received_dom_tree(JsonObject dom_tree, BlockToken block_token)
{
auto& walker_actor = devtools().register_actor<WalkerActor>(m_tab, move(dom_tree));
LibDevTools: Support highlighting DOM nodes hovered in the inspector
2025-02-20 08:58:35 -05:00
m_walker = walker_actor;
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 walker;
walker.set("actor"sv, walker_actor.name());
walker.set("root"sv, walker_actor.serialize_root());
JsonObject message;
message.set("from"sv, name());
message.set("walker"sv, move(walker));
send_message(move(message), move(block_token));
}
LibDevTools: Support highlighting DOM nodes hovered in the inspector
2025-02-20 08:58:35 -05:00
RefPtr<TabActor> InspectorActor::tab_for(WeakPtr<InspectorActor> const& weak_inspector)
{
if (auto inspector = weak_inspector.strong_ref())
return inspector->m_tab.strong_ref();
return {};
}
RefPtr<WalkerActor> InspectorActor::walker_for(WeakPtr<InspectorActor> const& weak_inspector)
{
if (auto inspector = weak_inspector.strong_ref())
return inspector->m_walker.strong_ref();
return {};
}
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
}
Reference in a new issue Copy permalink