Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-09 17:51:03 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibDevTools/Actors/PageStyleActor.h

38 lines
937 B
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
*/
#pragma once
#include <AK/NonnullRefPtr.h>
#include <LibDevTools/Actor.h>
LibDevTools+LibWebView+WebContent: Selectively fetch DOM node properties When we inspect a DOM node, we currently serialize many properties for that node, including its layout, computed style, used fonts, etc. Now that we aren't piggy-backing on the Inspector interface, we can instead only serialize the specific information required by DevTools.
2025-03-19 15:50:56 -04:00
#include <LibWebView/DOMNodeProperties.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 {
class PageStyleActor final : public Actor {
public:
static constexpr auto base_name = "page-style"sv;
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
static NonnullRefPtr<PageStyleActor> create(DevToolsServer&, String name, WeakPtr<InspectorActor>);
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
virtual ~PageStyleActor() override;
JsonValue serialize_style() const;
private:
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
PageStyleActor(DevToolsServer&, String name, WeakPtr<InspectorActor>);
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
virtual void handle_message(Message const&) override;
LibDevTools+LibWebView+WebContent: Selectively fetch DOM node properties When we inspect a DOM node, we currently serialize many properties for that node, including its layout, computed style, used fonts, etc. Now that we aren't piggy-backing on the Inspector interface, we can instead only serialize the specific information required by DevTools.
2025-03-19 15:50:56 -04:00
void inspect_dom_node(Message const&, WebView::DOMNodeProperties::Type);
void received_dom_node_properties(WebView::DOMNodeProperties const&);
LibDevTools: Support inspecting DOM node box models and computed styles
2025-02-21 16:20:53 -05:00
WeakPtr<InspectorActor> m_inspector;
LibDevTools+LibWebView+WebContent: Selectively fetch DOM node properties When we inspect a DOM node, we currently serialize many properties for that node, including its layout, computed style, used fonts, etc. Now that we aren't piggy-backing on the Inspector interface, we can instead only serialize the specific information required by DevTools.
2025-03-19 15:50:56 -04:00
Vector<Message, 1> m_pending_inspect_requests;
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