dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibDevTools/Actors/WatcherActor.cpp

321 lines
11 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 09:57:36 -03:00
/*
* Copyright (c) 2025, Tim Flynn <trflynn89@ladybird.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibDevTools: Begin supporting the JavaScript console This implements enough to execute JavaScript and reply with the result. We do not yet support autocomplete or eager evaluation.
2025-02-24 13:55:46 -03:00
#include <AK/Debug.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 09:57:36 -03:00
#include <AK/JsonObject.h>
#include <LibCore/EventLoop.h>
LibDevTools+LibWebView: Implement initial accessibility tree view This is enough for Firefox to display the Accessibility tab, containing our accessibility tree which can be inspected. Most information is blank for now. There's quite a bit of duplication between AccessibilityWalkerActor and WalkerActor - it might be worth trying to make a base class once the details are figured out. Frustratingly, the two don't work quite the same: for a lot of messages that would be sent to WalkerActor, the accessibility equivalent is sent to the AccessibilityNodeActor instead. Co-authored-by: Tim Flynn <trflynn89@pm.me>
2025-10-13 07:37:36 -03:00
#include <LibDevTools/Actors/AccessibilityActor.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 09:57:36 -03:00
#include <LibDevTools/Actors/CSSPropertiesActor.h>
LibDevTools: Begin supporting the JavaScript console This implements enough to execute JavaScript and reply with the result. We do not yet support autocomplete or eager evaluation.
2025-02-24 13:55:46 -03:00
#include <LibDevTools/Actors/ConsoleActor.h>
LibDevTools: Add cookie storage actor Firefox discovers Storage panel data through watcher resources. This adds a read-only cookies actor with the fields and empty store response expected by the Storage panel. Mutation traits are reported as unsupported for now. DevTools storage resources all have a "host" key derived from the URL, which we produce in `storage_host_for_url()`.
2026-06-11 06:15:14 -03:00
#include <LibDevTools/Actors/CookiesActor.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 09:57:36 -03:00
#include <LibDevTools/Actors/FrameActor.h>
#include <LibDevTools/Actors/InspectorActor.h>
LibDevTools: Add Firefox DevTools network monitoring support Hook ResourceLoader to emit network request lifecycle events through IPC to the UI process, where FrameActor creates NetworkEventActor instances that serialize requests using Firefox's Remote Debug Protocol. The Network panel now shows requests with method, URL, status, MIME type, size, and timing information. Several features remain stubbed (POST data, response content, cause detection) marked with FIXMEs.
2026-01-14 14:43:48 -03:00
#include <LibDevTools/Actors/NetworkParentActor.h>
LibDevTools: Populate DevTools Web Storage Firefox exposes localStorage and sessionStorage through the same storage actor protocol used by cookies. Add matching resources for the current tab so the Storage panel can list key/value pairs. Read the values through WebContent rather than directly from the browser process. Session storage lives in LibWeb, and using the same path for both stores keeps the actor independent of the backing store.
2026-06-10 12:15:21 -03:00
#include <LibDevTools/Actors/StorageActor.h>
LibDevTools+LibWebView: Implement getting document style sheets
2025-03-11 18:14:54 -03:00
#include <LibDevTools/Actors/StyleSheetsActor.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 09:57:36 -03:00
#include <LibDevTools/Actors/TabActor.h>
#include <LibDevTools/Actors/TargetConfigurationActor.h>
#include <LibDevTools/Actors/ThreadActor.h>
#include <LibDevTools/Actors/ThreadConfigurationActor.h>
#include <LibDevTools/Actors/WatcherActor.h>
LibDevTools: Reload inspector roots after navigation Firefox keeps using the same walker after navigation and expects it to publish the new document root. Normal tab debugging also relies on target switching. Re-inspect the tab when navigation finishes, replace the walker DOM data, and notify the watcher that the previous top-level frame target was destroyed before a fresh target becomes available. Send target availability as a watcher event, not as the watchTargets response, and give each navigation a new inner window id so Firefox can associate the new target with the new document.
2026-05-28 11:26:37 -03:00
#include <LibDevTools/DevToolsDelegate.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 09:57:36 -03:00
#include <LibDevTools/DevToolsServer.h>
namespace DevTools {
LibDevTools+LibWebView: Port DevTools to String
2025-02-19 11:28:02 -03:00
NonnullRefPtr<WatcherActor> WatcherActor::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 09:57:36 -03:00
{
return adopt_ref(*new WatcherActor(devtools, move(name), move(tab)));
}
LibDevTools+LibWebView: Port DevTools to String
2025-02-19 11:28:02 -03:00
WatcherActor::WatcherActor(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 09:57:36 -03:00
: Actor(devtools, move(name))
, m_tab(move(tab))
{
}
LibDevTools: Reload inspector roots after navigation Firefox keeps using the same walker after navigation and expects it to publish the new document root. Normal tab debugging also relies on target switching. Re-inspect the tab when navigation finishes, replace the walker DOM data, and notify the watcher that the previous top-level frame target was destroyed before a fresh target becomes available. Send target availability as a watcher event, not as the watchTargets response, and give each navigation a new inner window id so Firefox can associate the new target with the new document.
2026-05-28 11:26:37 -03:00
WatcherActor::~WatcherActor()
{
if (!m_is_watching_frame_targets)
return;
if (auto tab = m_tab.strong_ref())
devtools().delegate().did_disconnect_devtools_client(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 09:57:36 -03:00
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 09:01:23 -03:00
void WatcherActor::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 09:57:36 -03:00
{
JsonObject response;
LibDevTools: Add Firefox DevTools network monitoring support Hook ResourceLoader to emit network request lifecycle events through IPC to the UI process, where FrameActor creates NetworkEventActor instances that serialize requests using Firefox's Remote Debug Protocol. The Network panel now shows requests with method, URL, status, MIME type, size, and timing information. Several features remain stubbed (POST data, response content, cause detection) marked with FIXMEs.
2026-01-14 14:43:48 -03:00
if (message.type == "getNetworkParentActor"sv) {
if (!m_network_parent)
m_network_parent = devtools().register_actor<NetworkParentActor>();
response.set("network"sv, m_network_parent->name());
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 09:01:23 -03:00
if (message.type == "getParentBrowsingContextID"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 10:05:01 -03:00
auto browsing_context_id = get_required_parameter<u64>(message, "browsingContextID"sv);
if (!browsing_context_id.has_value())
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 09:57:36 -03:00
return;
response.set("browsingContextID"sv, *browsing_context_id);
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 13:26:58 -03:00
send_response(message, move(response));
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 09:57:36 -03: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 09:01:23 -03:00
if (message.type == "getTargetConfigurationActor"sv) {
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 09:57:36 -03:00
if (!m_target_configuration)
m_target_configuration = devtools().register_actor<TargetConfigurationActor>();
response.set("configuration"sv, m_target_configuration->serialize_configuration());
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 13:26:58 -03:00
send_response(message, move(response));
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 09:57:36 -03: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 09:01:23 -03:00
if (message.type == "getThreadConfigurationActor"sv) {
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 09:57:36 -03:00
if (!m_thread_configuration)
m_thread_configuration = devtools().register_actor<ThreadConfigurationActor>();
response.set("configuration"sv, m_thread_configuration->serialize_configuration());
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 13:26:58 -03:00
send_response(message, move(response));
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 09:57:36 -03: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 09:01:23 -03:00
if (message.type == "watchResources"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 10:05:01 -03:00
auto resource_types = get_required_parameter<JsonArray>(message, "resourceTypes"sv);
if (!resource_types.has_value())
LibDevTools: Begin supporting the JavaScript console This implements enough to execute JavaScript and reply with the result. We do not yet support autocomplete or eager evaluation.
2025-02-24 13:55:46 -03:00
return;
LibDevTools: Add cookie storage actor Firefox discovers Storage panel data through watcher resources. This adds a read-only cookies actor with the fields and empty store response expected by the Storage panel. Mutation traits are reported as unsupported for now. DevTools storage resources all have a "host" key derived from the URL, which we produce in `storage_host_for_url()`.
2026-06-11 06:15:14 -03:00
bool should_send_cookie_resources = false;
LibDevTools: Populate DevTools Web Storage Firefox exposes localStorage and sessionStorage through the same storage actor protocol used by cookies. Add matching resources for the current tab so the Storage panel can list key/value pairs. Read the values through WebContent rather than directly from the browser process. Session storage lives in LibWeb, and using the same path for both stores keeps the actor independent of the backing store.
2026-06-10 12:15:21 -03:00
bool should_send_local_storage_resources = false;
bool should_send_session_storage_resources = false;
LibDevTools: Begin supporting the JavaScript console This implements enough to execute JavaScript and reply with the result. We do not yet support autocomplete or eager evaluation.
2025-02-24 13:55:46 -03:00
if constexpr (DEVTOOLS_DEBUG) {
for (auto const& resource_type : resource_types->values()) {
if (!resource_type.is_string())
continue;
LibDevTools: Populate DevTools Web Storage Firefox exposes localStorage and sessionStorage through the same storage actor protocol used by cookies. Add matching resources for the current tab so the Storage panel can list key/value pairs. Read the values through WebContent rather than directly from the browser process. Session storage lives in LibWeb, and using the same path for both stores keeps the actor independent of the backing store.
2026-06-10 12:15:21 -03:00
if (!first_is_one_of(resource_type.as_string(), "console-message"sv, "cookies"sv, "local-storage"sv, "session-storage"sv))
LibDevTools: Begin supporting the JavaScript console This implements enough to execute JavaScript and reply with the result. We do not yet support autocomplete or eager evaluation.
2025-02-24 13:55:46 -03:00
dbgln("Unrecognized `watchResources` resource type: '{}'", resource_type.as_string());
}
}
LibDevTools: Add cookie storage actor Firefox discovers Storage panel data through watcher resources. This adds a read-only cookies actor with the fields and empty store response expected by the Storage panel. Mutation traits are reported as unsupported for now. DevTools storage resources all have a "host" key derived from the URL, which we produce in `storage_host_for_url()`.
2026-06-11 06:15:14 -03:00
for (auto const& resource_type : resource_types->values()) {
if (!resource_type.is_string())
continue;
if (resource_type.as_string() == "cookies"sv) {
m_is_watching_cookie_resources = true;
should_send_cookie_resources = true;
LibDevTools: Populate DevTools Web Storage Firefox exposes localStorage and sessionStorage through the same storage actor protocol used by cookies. Add matching resources for the current tab so the Storage panel can list key/value pairs. Read the values through WebContent rather than directly from the browser process. Session storage lives in LibWeb, and using the same path for both stores keeps the actor independent of the backing store.
2026-06-10 12:15:21 -03:00
} else if (resource_type.as_string() == "local-storage"sv) {
m_is_watching_local_storage_resources = true;
should_send_local_storage_resources = true;
} else if (resource_type.as_string() == "session-storage"sv) {
m_is_watching_session_storage_resources = true;
should_send_session_storage_resources = true;
LibDevTools: Add cookie storage actor Firefox discovers Storage panel data through watcher resources. This adds a read-only cookies actor with the fields and empty store response expected by the Storage panel. Mutation traits are reported as unsupported for now. DevTools storage resources all have a "host" key derived from the URL, which we produce in `storage_host_for_url()`.
2026-06-11 06:15:14 -03:00
}
}
LibDevTools: Begin supporting the JavaScript console This implements enough to execute JavaScript and reply with the result. We do not yet support autocomplete or eager evaluation.
2025-02-24 13:55:46 -03:00
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 13:26:58 -03:00
send_response(message, move(response));
LibDevTools: Add cookie storage actor Firefox discovers Storage panel data through watcher resources. This adds a read-only cookies actor with the fields and empty store response expected by the Storage panel. Mutation traits are reported as unsupported for now. DevTools storage resources all have a "host" key derived from the URL, which we produce in `storage_host_for_url()`.
2026-06-11 06:15:14 -03:00
if (should_send_cookie_resources)
send_cookies_resource_available_message();
LibDevTools: Populate DevTools Web Storage Firefox exposes localStorage and sessionStorage through the same storage actor protocol used by cookies. Add matching resources for the current tab so the Storage panel can list key/value pairs. Read the values through WebContent rather than directly from the browser process. Session storage lives in LibWeb, and using the same path for both stores keeps the actor independent of the backing store.
2026-06-10 12:15:21 -03:00
if (should_send_local_storage_resources)
send_storage_resource_available_message(local_storage_actor());
if (should_send_session_storage_resources)
send_storage_resource_available_message(session_storage_actor());
LibDevTools: Begin supporting the JavaScript console This implements enough to execute JavaScript and reply with the result. We do not yet support autocomplete or eager evaluation.
2025-02-24 13:55:46 -03: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 09:01:23 -03:00
if (message.type == "watchTargets"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 10:05:01 -03:00
auto target_type = get_required_parameter<String>(message, "targetType"sv);
if (!target_type.has_value())
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 09:57:36 -03:00
return;
if (target_type == "frame"sv) {
LibDevTools: Reload inspector roots after navigation Firefox keeps using the same walker after navigation and expects it to publish the new document root. Normal tab debugging also relies on target switching. Re-inspect the tab when navigation finishes, replace the walker DOM data, and notify the watcher that the previous top-level frame target was destroyed before a fresh target becomes available. Send target availability as a watcher event, not as the watchTargets response, and give each navigation a new inner window id so Firefox can associate the new target with the new document.
2026-05-28 11:26:37 -03:00
if (!m_is_watching_frame_targets) {
if (auto tab = m_tab.strong_ref())
devtools().delegate().did_connect_devtools_client(tab->description());
m_is_watching_frame_targets = true;
}
auto& target = create_frame_target();
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 13:26:58 -03:00
send_response(message, move(response));
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 09:57:36 -03:00
LibDevTools: Reload inspector roots after navigation Firefox keeps using the same walker after navigation and expects it to publish the new document root. Normal tab debugging also relies on target switching. Re-inspect the tab when navigation finishes, replace the walker DOM data, and notify the watcher that the previous top-level frame target was destroyed before a fresh target becomes available. Send target availability as a watcher event, not as the watchTargets response, and give each navigation a new inner window id so Firefox can associate the new target with the new document.
2026-05-28 11:26:37 -03:00
send_frame_target_available_message(target);
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 09:57:36 -03:00
target.send_frame_update_message();
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 09:01:23 -03: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 09:57:36 -03:00
}
JsonObject WatcherActor::serialize_description() const
{
JsonObject resources;
resources.set("Cache"sv, false);
LibDevTools: Begin supporting the JavaScript console This implements enough to execute JavaScript and reply with the result. We do not yet support autocomplete or eager evaluation.
2025-02-24 13:55:46 -03:00
resources.set("console-message"sv, true);
LibDevTools: Add cookie storage actor Firefox discovers Storage panel data through watcher resources. This adds a read-only cookies actor with the fields and empty store response expected by the Storage panel. Mutation traits are reported as unsupported for now. DevTools storage resources all have a "host" key derived from the URL, which we produce in `storage_host_for_url()`.
2026-06-11 06:15:14 -03:00
resources.set("cookies"sv, true);
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 09:57:36 -03:00
resources.set("css-change"sv, false);
resources.set("css-message"sv, false);
resources.set("css-registered-properties"sv, false);
LibDevTools: Send navigation events to Firefox DevTools When a page navigates, send document-event resources with "will-navigate" and tabNavigated messages so Firefox DevTools can follow along and clear the Network panel appropriately.
2026-01-14 15:03:16 -03:00
resources.set("document-event"sv, true);
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 09:57:36 -03:00
resources.set("error-message"sv, false);
resources.set("extension-storage"sv, false);
resources.set("indexed-db"sv, false);
resources.set("jstracer-state"sv, false);
resources.set("jstracer-trace"sv, false);
resources.set("last-private-context-exit"sv, false);
LibDevTools: Populate DevTools Web Storage Firefox exposes localStorage and sessionStorage through the same storage actor protocol used by cookies. Add matching resources for the current tab so the Storage panel can list key/value pairs. Read the values through WebContent rather than directly from the browser process. Session storage lives in LibWeb, and using the same path for both stores keeps the actor independent of the backing store.
2026-06-10 12:15:21 -03:00
resources.set("local-storage"sv, true);
LibDevTools: Add Firefox DevTools network monitoring support Hook ResourceLoader to emit network request lifecycle events through IPC to the UI process, where FrameActor creates NetworkEventActor instances that serialize requests using Firefox's Remote Debug Protocol. The Network panel now shows requests with method, URL, status, MIME type, size, and timing information. Several features remain stubbed (POST data, response content, cause detection) marked with FIXMEs.
2026-01-14 14:43:48 -03:00
resources.set("network-event"sv, true);
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 09:57:36 -03:00
resources.set("network-event-stacktrace"sv, false);
resources.set("platform-message"sv, false);
resources.set("reflow"sv, false);
resources.set("server-sent-event"sv, false);
LibDevTools: Populate DevTools Web Storage Firefox exposes localStorage and sessionStorage through the same storage actor protocol used by cookies. Add matching resources for the current tab so the Storage panel can list key/value pairs. Read the values through WebContent rather than directly from the browser process. Session storage lives in LibWeb, and using the same path for both stores keeps the actor independent of the backing store.
2026-06-10 12:15:21 -03:00
resources.set("session-storage"sv, true);
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 09:57:36 -03:00
resources.set("source"sv, false);
resources.set("stylesheet"sv, false);
resources.set("thread-state"sv, false);
resources.set("websocket"sv, false);
JsonObject description;
description.set("shared_worker"sv, false);
description.set("service_worker"sv, false);
description.set("frame"sv, true);
description.set("process"sv, false);
description.set("worker"sv, false);
description.set("resources"sv, move(resources));
return description;
}
LibDevTools: Reload inspector roots after navigation Firefox keeps using the same walker after navigation and expects it to publish the new document root. Normal tab debugging also relies on target switching. Re-inspect the tab when navigation finishes, replace the walker DOM data, and notify the watcher that the previous top-level frame target was destroyed before a fresh target becomes available. Send target availability as a watcher event, not as the watchTargets response, and give each navigation a new inner window id so Firefox can associate the new target with the new document.
2026-05-28 11:26:37 -03:00
FrameActor& WatcherActor::create_frame_target()
{
auto& css_properties = devtools().register_actor<CSSPropertiesActor>();
auto& console = devtools().register_actor<ConsoleActor>(m_tab);
auto& style_sheets = devtools().register_actor<StyleSheetsActor>(m_tab);
LibWeb+LibDevTools: Link style rules to CSS sources Resolve applied-rule stylesheet identities through StyleSheetsActor and include Firefox parentStyleSheet, line, and column fields on rule forms. Firefox can then show matched rules as stylesheet rules and open the corresponding CSS source location from the Rules panel.
2026-06-03 09:07:55 -03:00
auto& inspector = devtools().register_actor<InspectorActor>(m_tab, style_sheets);
LibDevTools: Reload inspector roots after navigation Firefox keeps using the same walker after navigation and expects it to publish the new document root. Normal tab debugging also relies on target switching. Re-inspect the tab when navigation finishes, replace the walker DOM data, and notify the watcher that the previous top-level frame target was destroyed before a fresh target becomes available. Send target availability as a watcher event, not as the watchTargets response, and give each navigation a new inner window id so Firefox can associate the new target with the new document.
2026-05-28 11:26:37 -03:00
auto& thread = devtools().register_actor<ThreadActor>();
auto& accessibility = devtools().register_actor<AccessibilityActor>(m_tab);
auto& target = devtools().register_actor<FrameActor>(m_tab, make_weak_ptr<WatcherActor>(), css_properties, console, inspector, style_sheets, thread, accessibility);
m_target = target;
return target;
}
void WatcherActor::send_frame_target_available_message()
{
auto& target = create_frame_target();
send_frame_target_available_message(target);
}
void WatcherActor::switch_frame_target(FrameActor& previous_target, String const& url, String const& title)
{
auto previous_target_ref = m_target.strong_ref();
if (!previous_target_ref || previous_target_ref.ptr() != &previous_target)
return;
send_frame_target_destroyed_message(*previous_target_ref);
previous_target_ref->stop_listening();
devtools().unregister_actor(previous_target_ref->name());
auto& target = create_frame_target();
send_frame_target_available_message(target);
target.send_frame_update_message();
target.set_pending_navigation_document_events_after_target_switch(url, title);
LibDevTools: Add cookie storage actor Firefox discovers Storage panel data through watcher resources. This adds a read-only cookies actor with the fields and empty store response expected by the Storage panel. Mutation traits are reported as unsupported for now. DevTools storage resources all have a "host" key derived from the URL, which we produce in `storage_host_for_url()`.
2026-06-11 06:15:14 -03:00
if (m_is_watching_cookie_resources)
send_cookies_resource_available_message();
LibDevTools: Populate DevTools Web Storage Firefox exposes localStorage and sessionStorage through the same storage actor protocol used by cookies. Add matching resources for the current tab so the Storage panel can list key/value pairs. Read the values through WebContent rather than directly from the browser process. Session storage lives in LibWeb, and using the same path for both stores keeps the actor independent of the backing store.
2026-06-10 12:15:21 -03:00
if (m_is_watching_local_storage_resources)
send_storage_resource_available_message(local_storage_actor());
if (m_is_watching_session_storage_resources)
send_storage_resource_available_message(session_storage_actor());
LibDevTools: Reload inspector roots after navigation Firefox keeps using the same walker after navigation and expects it to publish the new document root. Normal tab debugging also relies on target switching. Re-inspect the tab when navigation finishes, replace the walker DOM data, and notify the watcher that the previous top-level frame target was destroyed before a fresh target becomes available. Send target availability as a watcher event, not as the watchTargets response, and give each navigation a new inner window id so Firefox can associate the new target with the new document.
2026-05-28 11:26:37 -03:00
}
void WatcherActor::send_frame_target_available_message(FrameActor& target)
{
JsonObject message;
message.set("type"sv, "target-available-form"sv);
message.set("target"sv, target.serialize_target());
send_message(move(message));
}
void WatcherActor::send_frame_target_destroyed_message(FrameActor& target)
{
JsonObject options;
options.set("isTargetSwitching"sv, true);
options.set("shouldDestroyTargetFront"sv, true);
JsonObject message;
message.set("type"sv, "target-destroyed-form"sv);
message.set("target"sv, target.serialize_target());
message.set("options"sv, move(options));
send_message(move(message));
}
LibDevTools: Add cookie storage actor Firefox discovers Storage panel data through watcher resources. This adds a read-only cookies actor with the fields and empty store response expected by the Storage panel. Mutation traits are reported as unsupported for now. DevTools storage resources all have a "host" key derived from the URL, which we produce in `storage_host_for_url()`.
2026-06-11 06:15:14 -03:00
CookiesActor& WatcherActor::cookies_actor()
{
if (auto cookies = m_cookies.strong_ref())
return *cookies;
m_cookies = devtools().register_actor<CookiesActor>(m_tab);
return *m_cookies.strong_ref();
}
void WatcherActor::send_cookies_resource_available_message()
{
JsonArray cookies;
cookies.must_append(cookies_actor().serialize_storage());
JsonArray cookie_resources;
cookie_resources.must_append("cookies"sv);
cookie_resources.must_append(move(cookies));
JsonArray array;
array.must_append(move(cookie_resources));
JsonObject message;
message.set("type"sv, "resources-available-array"sv);
message.set("array"sv, move(array));
send_message(move(message));
}
LibDevTools: Populate DevTools Web Storage Firefox exposes localStorage and sessionStorage through the same storage actor protocol used by cookies. Add matching resources for the current tab so the Storage panel can list key/value pairs. Read the values through WebContent rather than directly from the browser process. Session storage lives in LibWeb, and using the same path for both stores keeps the actor independent of the backing store.
2026-06-10 12:15:21 -03:00
StorageActor& WatcherActor::local_storage_actor()
{
if (auto storage = m_local_storage.strong_ref())
return *storage;
m_local_storage = devtools().register_actor<StorageActor>(m_tab, Web::StorageAPI::StorageEndpointType::LocalStorage);
return *m_local_storage.strong_ref();
}
StorageActor& WatcherActor::session_storage_actor()
{
if (auto storage = m_session_storage.strong_ref())
return *storage;
m_session_storage = devtools().register_actor<StorageActor>(m_tab, Web::StorageAPI::StorageEndpointType::SessionStorage);
return *m_session_storage.strong_ref();
}
void WatcherActor::send_storage_resource_available_message(StorageActor& storage)
{
JsonArray resources;
resources.must_append(storage.serialize_storage());
JsonArray typed_resources;
typed_resources.must_append(storage.resource_type());
typed_resources.must_append(move(resources));
JsonArray array;
array.must_append(move(typed_resources));
JsonObject message;
message.set("type"sv, "resources-available-array"sv);
message.set("array"sv, move(array));
send_message(move(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 09:57:36 -03:00
}
Reference in a new issue Copy permalink