Firefox starts element picking by sending pick to the walker actor. Add
matching protocol handling so Ladybird can enter picker mode, send
hover, preview, pick, and cancel events, and serialize picked nodes in
the shape Firefox expects.
Picker hit testing can return text nodes, but Firefox only selects
elements in this mode. Normalize picker events to the closest element
ancestor and include the parent chain so Firefox can materialize missing
tree nodes before selecting the target.
Firefox creates a new custom highlighter actor for each
getHighlighterByType request. Its frontend decides when to cache and
reuse those actors, while grid highlighting uses distinct actors so
multiple grids and subgrid parent overlays can remain visible at the
same time.
Match that allocation model by removing InspectorActor's server-side
highlighter cache. Also unregister highlighter actors after release or
finalize, and make each actor clear only the highlight state it owns.
Firefox's grid inspector builds its subgrid tree from two protocol
signals: isSubgrid on each GridActor form, and
Walker.getParentGridNode() for each subgrid container. Teach the walker
to answer the parent grid lookup so Firefox can attach subgrids below
their parent grid in the Layout panel.
Create typed highlighter actors for Firefox's highlighter requests.
The actor keeps the requested type so CssGridHighlighter can use grid
highlighting while the other highlighter types keep the existing box
model-compatible behavior.
Teach the walker to vend a layout inspector actor and serialize node
display types.
The layout inspector now returns Firefox-compatible grid actor forms
for getGrids and getCurrentGrid. It also supports Firefox's fallback
walker.getNodeFromActor(grid, ["containerEl"]) path, which the grid
panel uses when a grid form does not already contain a container node
actor ID.
Add IPC structures and requests for inspecting grid layout data from
WebContent.
WebView forwards the async replies to LibDevTools and exposes the grid
highlighter hooks used by the protocol layer.
Parse Firefox grid highlighter options in WebContent and store them with
the active grid highlight.
We have a common pattern of creating a `WeakPtr<T>` from a reference and
passing that into a lambda, to then take the strong ref when the lambda
is executed. Add `weak_callback(Weakable, lambda)` that returns a lambda
that only invokes the callback if a strong ref exists, and passes it as
the first argument.
LibJS+DevTools: Implement console.trace() with source locations
- Add Console::TraceFrame struct with source location data
- Implement Console::trace() to gather stack information
- Add WebView::StackFrame and ConsoleTrace for IPC
- Implement DevToolsConsoleClient::printer() for traces
- Update FrameActor to format traces for DevTools
- Update WorkerDebugConsoleClient trace handling
- Update ReplConsoleClient to format trace output
To avoid unnecessary IPC traffic, we now only send network response
bodies when a DevTools client is connected.
This requires tracking DevTools connection state in ViewImplementation
so we can propagate it to new WebContent processes created during
cross-site navigation.
Use blocking mode for socket writes to ensure large response bodies
(like 1MB+ HTML pages) are fully written without EAGAIN errors. The
socket is temporarily set to blocking mode during the write operation.
Also improve error handling by logging failed sends with the message
size and error details.
Additionally, when response content claims to be text but isn't valid
UTF-8, fall back to base64 encoding instead of returning empty content.
Propagate the request initiator type (e.g., "xmlhttprequest", "fetch",
"script", "stylesheet") from LibWeb through the IPC layer to DevTools.
This enables Firefox DevTools to correctly identify XHR/fetch requests
and display appropriate cause types in the Network panel's "Initiator"
column.
This adds support for viewing request payloads (POST data) and response
bodies in the Firefox DevTools network panel.
Request bodies are captured when network requests start and passed
through IPC to the NetworkEventActor, which returns them via the
getRequestPostData protocol method.
Response bodies are streamed via a new IPC message as data is received,
accumulated in NetworkEventActor (with a 10MB size limit to prevent
memory issues), and returned via getResponseContent. Text content is
returned as UTF-8, while binary content (images, etc.) is base64.
Previously, console messages were sent using an index-based system where
DevTools would be notified of new message indices and then request them
in batches. This created synchronization issues during page navigation
when the WebContent process resets while DevTools still has stale index
state.
This changes to a push-based model where console messages are sent
immediately as resources when they are logged, matching how Firefox
DevTools handles console messages. Each message is pushed through IPC
and forwarded to DevTools as a "console-message" or "error-message"
resource.
This eliminates the need for index tracking in FrameActor and simplifies
the entire console message pipeline from WebContent through to 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.
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.
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>
Width and height are doubles, so get_string() will return nothing and
fail. We just want a JsonValue here without caring what type it is, so
let's just use get() instead.
We were ignoring the dom_element_unique_id field, which meant if we had
more than one inline style sheet on a page, we would not distinguish
between them. This had the effect of halting the style sheet loading
process in the dev tools, with none appearing.
Mark UA style sheets as "system", which makes them read-only in the
Firefox dev tools. Also give them an href with a fake resource:// URL so
that they don't appear as "<inline style sheet>", and don't set the href
for actual inline style sheets, for the opposite reason.
I've kept the title for UA style sheets, because that means we see
`Thing/Default.css` instead of just `Default.css` for all of them.
In particular, if a node does not have a computed style, we must still
include the "computed" object in the response. Otherwise, DevTools will
continue to display the properties from the previously selected node.
The upcoming generated types will match those for pseudo-classes: A
PseudoElementSelector type, that then holds a PseudoElement enum
defining what it is. That enum will be at the top level in the Web::CSS
namespace.
In order to keep the diffs clearer, this commit renames and moves the
types, and then a following one will replace the handwritten enum with
a generated one.
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.
Now that we aren't piggy-backing on the Inspector interface, we can make
our box-model serialization provide exactly the values that DevTools
requires.
The NodeIdentifier struct essentially contains the DOM node ID within
its WebContent process. These will repeat across multiple processes,
thus we cannot use them to search for node actors in the global actor
registry.
Instead, we can store a map of all node actors created by the walker
itself. The NodeIdentifier is then appropriate for actor lookups on
that map. This has the added benefit of not needing to search the entire
actor registry many times while forming the DOM node caches.
This fix allows us to inspect multiple tabs at once.
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).
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.
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.
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.
The "from" field is required in every response. It is the name of the
actor sending the message. This patch fills in the "from" field in the
Actor base class so that subclasses don't have to.
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.
These commands are used for the "Edit As HTML" feature in DevTools. This
renames our existing HTML getter IPC to indicate that it is for outer
HTML. DevTools will need a separate inner HTML getter.
This requires a couple of amendments to the DOM node serialization.
Namely, we need to include the HTML namespace, otherwise the context
menu item to create a new node is disabled.
