Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-01 13:50:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibDevTools/Actors/PageStyleActor.cpp

211 lines
7.5 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
*/
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
#include <AK/JsonValue.h>
#include <LibDevTools/Actors/InspectorActor.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
#include <LibDevTools/Actors/PageStyleActor.h>
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
#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: Add a helper to handle asynchronous request replies 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.
2025-03-11 09:47:41 -04:00
static void received_layout(JsonObject& response, JsonObject const& computed_style, JsonObject const& node_box_sizing)
{
response.set("autoMargins"sv, JsonObject {});
auto pixel_value = [&](auto const& object, auto key) {
return object.get_double_with_precision_loss(key).value_or(0);
};
auto set_pixel_value_from = [&](auto const& object, auto object_key, auto message_key) {
response.set(message_key, MUST(String::formatted("{}px", pixel_value(object, object_key))));
};
auto set_computed_value_from = [&](auto const& object, auto key) {
response.set(key, object.get_string(key).value_or(String {}));
};
response.set("width"sv, pixel_value(node_box_sizing, "content_width"sv));
response.set("height"sv, pixel_value(node_box_sizing, "content_height"sv));
// FIXME: This response should also contain "top", "right", "bottom", and "left", but our box model metrics in
// WebContent do not provide this information.
set_pixel_value_from(node_box_sizing, "border_top"sv, "border-top-width"sv);
set_pixel_value_from(node_box_sizing, "border_right"sv, "border-right-width"sv);
set_pixel_value_from(node_box_sizing, "border_bottom"sv, "border-bottom-width"sv);
set_pixel_value_from(node_box_sizing, "border_left"sv, "border-left-width"sv);
set_pixel_value_from(node_box_sizing, "margin_top"sv, "margin-top"sv);
set_pixel_value_from(node_box_sizing, "margin_right"sv, "margin-right"sv);
set_pixel_value_from(node_box_sizing, "margin_bottom"sv, "margin-bottom"sv);
set_pixel_value_from(node_box_sizing, "margin_left"sv, "margin-left"sv);
set_pixel_value_from(node_box_sizing, "padding_top"sv, "padding-top"sv);
set_pixel_value_from(node_box_sizing, "padding_right"sv, "padding-right"sv);
set_pixel_value_from(node_box_sizing, "padding_bottom"sv, "padding-bottom"sv);
set_pixel_value_from(node_box_sizing, "padding_left"sv, "padding-left"sv);
set_computed_value_from(computed_style, "box-sizing"sv);
set_computed_value_from(computed_style, "display"sv);
set_computed_value_from(computed_style, "float"sv);
set_computed_value_from(computed_style, "line-height"sv);
set_computed_value_from(computed_style, "position"sv);
set_computed_value_from(computed_style, "z-index"sv);
}
static void received_computed_style(JsonObject& response, JsonObject const& computed_style)
{
JsonObject computed;
computed_style.for_each_member([&](String const& name, JsonValue const& value) {
JsonObject property;
property.set("matched"sv, true);
property.set("value"sv, value);
computed.set(name, move(property));
});
response.set("computed"sv, move(computed));
}
LibDevTools+LibWebView: Implement getting the used fonts for a DOM node This also includes a request to get all fonts for a page, which we stub out for now as we don't have the IPC to retrieve all fonts.
2025-03-11 16:01:34 -04:00
static void received_fonts(JsonObject& response, JsonArray const& fonts)
{
JsonArray font_faces;
fonts.for_each([&](JsonValue const& font) {
if (!font.is_object())
return;
auto name = font.as_object().get_string("name"sv).value_or({});
auto weight = font.as_object().get_integer<i64>("weight"sv).value_or(0);
JsonObject font_face;
font_face.set("CSSFamilyName"sv, name);
font_face.set("CSSGeneric"sv, JsonValue {});
font_face.set("format"sv, ""sv);
font_face.set("localName"sv, ""sv);
font_face.set("metadata"sv, ""sv);
font_face.set("name"sv, name);
font_face.set("srcIndex"sv, -1);
font_face.set("style"sv, ""sv);
font_face.set("URI"sv, ""sv);
font_face.set("variationAxes"sv, JsonArray {});
font_face.set("variationInstances"sv, JsonArray {});
font_face.set("weight"sv, weight);
font_faces.must_append(move(font_face));
});
response.set("fontFaces"sv, move(font_faces));
}
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
NonnullRefPtr<PageStyleActor> PageStyleActor::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 inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
return adopt_ref(*new PageStyleActor(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 inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
PageStyleActor::PageStyleActor(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 inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -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
{
}
PageStyleActor::~PageStyleActor() = default;
LibDevTools: Move message data into a structure 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.
2025-03-12 08:01:23 -04:00
void PageStyleActor::handle_message(Message 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
{
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
JsonObject response;
LibDevTools+LibWebView: Implement getting the used fonts for a DOM node This also includes a request to get all fonts for a page, which we stub out for now as we don't have the IPC to retrieve all fonts.
2025-03-11 16:01:34 -04:00
if (message.type == "getAllUsedFontFaces"sv) {
response.set("fontFaces"sv, JsonArray {});
send_response(message, move(response));
return;
}
LibDevTools: Move message data into a structure 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.
2025-03-12 08:01:23 -04:00
if (message.type == "getApplied"sv) {
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
// FIXME: This provides information to the "styles" pane in the inspector tab, which allows toggling and editing
// styles live. We do not yet support figuring out the list of styles that apply to a specific node.
response.set("entries"sv, JsonArray {});
LibDevTools: Re-implement how we handle ordered responses 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).
2025-03-12 12:26:58 -04:00
send_response(message, move(response));
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
return;
}
LibDevTools: Move message data into a structure 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.
2025-03-12 08:01:23 -04:00
if (message.type == "getComputed"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 inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
return;
LibDevTools: Re-implement how we handle ordered responses 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).
2025-03-12 12:26:58 -04:00
inspect_dom_node(message, *node, [](auto& response, auto const& properties) {
LibDevTools: Add a helper to handle asynchronous request replies 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.
2025-03-11 09:47:41 -04:00
received_computed_style(response, properties.computed_style);
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
});
return;
}
LibDevTools: Move message data into a structure 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.
2025-03-12 08:01:23 -04:00
if (message.type == "getLayout"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 inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
return;
LibDevTools: Re-implement how we handle ordered responses 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).
2025-03-12 12:26:58 -04:00
inspect_dom_node(message, *node, [](auto& response, auto const& properties) {
LibDevTools: Add a helper to handle asynchronous request replies 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.
2025-03-11 09:47:41 -04:00
received_layout(response, properties.computed_style, properties.node_box_sizing);
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
});
return;
}
LibDevTools+LibWebView: Implement getting the used fonts for a DOM node This also includes a request to get all fonts for a page, which we stub out for now as we don't have the IPC to retrieve all fonts.
2025-03-11 16:01:34 -04:00
if (message.type == "getUsedFontFaces"sv) {
auto node = get_required_parameter<String>(message, "node"sv);
if (!node.has_value())
return;
inspect_dom_node(message, *node, [](auto& response, auto const& properties) {
received_fonts(response, properties.fonts);
});
return;
}
LibDevTools: Move message data into a structure 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.
2025-03-12 08:01:23 -04:00
if (message.type == "isPositionEditable") {
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
response.set("value"sv, false);
LibDevTools: Re-implement how we handle ordered responses 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).
2025-03-12 12:26:58 -04:00
send_response(message, move(response));
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
return;
}
LibDevTools: Move message data into a structure 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.
2025-03-12 08:01:23 -04:00
send_unrecognized_packet_type_error(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
}
JsonValue PageStyleActor::serialize_style() const
{
JsonObject traits;
traits.set("fontStyleLevel4"sv, true);
traits.set("fontWeightLevel4"sv, true);
traits.set("fontStretchLevel4"sv, true);
traits.set("fontVariations"sv, true);
JsonObject style;
style.set("actor"sv, name());
style.set("traits"sv, move(traits));
return style;
}
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
template<typename Callback>
LibDevTools: Re-implement how we handle ordered responses 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).
2025-03-12 12:26:58 -04:00
void PageStyleActor::inspect_dom_node(Message const& message, StringView node_actor, Callback&& callback)
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
{
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
auto dom_node = WalkerActor::dom_node_for(InspectorActor::walker_for(m_inspector), node_actor);
LibDevTools: Send an unknown actor error for failed DOM node lookups 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.
2025-03-11 07:55:05 -04:00
if (!dom_node.has_value()) {
LibDevTools: Re-implement how we handle ordered responses 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).
2025-03-12 12:26:58 -04:00
send_unknown_actor_error(message, node_actor);
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
return;
LibDevTools: Send an unknown actor error for failed DOM node lookups 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.
2025-03-11 07:55:05 -04:00
}
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
LibDevTools: Add a helper to handle asynchronous request replies 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.
2025-03-11 09:47:41 -04:00
devtools().delegate().inspect_dom_node(dom_node->tab->description(), dom_node->identifier.id, dom_node->identifier.pseudo_element,
LibDevTools: Re-implement how we handle ordered responses 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).
2025-03-12 12:26:58 -04:00
async_handler(message, [callback = forward<Callback>(callback)](auto&, auto properties, auto& response) {
LibDevTools: Add a helper to handle asynchronous request replies 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.
2025-03-11 09:47:41 -04:00
callback(response, properties);
}));
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -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
}
Reference in a new issue Copy permalink