Enqueuing while processing the navigation queue is rare, but apparently can
happen. The most likely culprit is the microqueue task being processed which
enqueues a new navigation (e.g. when a promise resolves).
This was never well handled, with the possibility of a use-after-free or of
skipping the new navigation. This commit introduces a double queue, which is
swapped at the start of processing, so that we always have 1 list for queueing
new navigation requests, and one list that we're currently processing.
This is done for a couple reasons. The first is just to have things a little
more self-contained for eventually supporting more advanced "wait" logic, e.g.
waiting for a selector.
The other is to provide callers with more fine-grained controlled. Specifically
the ability to manually "tick", so that they can [presumably] do something
after every tick. This is needed by the test runner to support more advanced
cases (cases that need to test beyond 'load') and it also improves (and fixes
potential use-after-free, the lp.waitForSelector)
After click, fill, and scroll actions, return the current page URL
and title instead of static success messages. This gives AI agents
immediate feedback about the page state after an action, matching
the pattern already used by waitForSelector.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add three test cases covering:
- Immediate match on an already-present element
- Polling match on an element added after a 200ms setTimeout delay
- Timeout error on a non-existent element with a short timeout
Add mcp_wait_for_selector.html test fixture that injects a #delayed
element after 200ms via setTimeout for the polling test.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Extract Document.replaceChildren, Element.replaceChildren and
DocumentFragment.replaceChildren into a common helper, Node.replaceChildren.
Fixes an infinite loop in WPT test:
/dom/nodes/ParentNode-replaceChildren.html
Add correct handling for new URL('about:blank');
When a frame is navigated to about:blank (which happens often, since it happens
as soon as a dynamic iframe is created), we make sure to give window._location
a unique value. This prevents 2 frames from referencing the same
window._location object.
Fixes a WPT crash in: 0/html/browsers/browsing-the-web/navigating-across-documents/initial-empty-document/iframe-nosrc.html
When the base page (*cough* frame *cough*) is about:blank, then we need to go
up the parents to find the actual base url to resolve any new navigation URLs.
Adds a waitForSelector tool to the MCP server that polls for a CSS
selector match with a configurable timeout (default 5000ms). Returns the
backendNodeId of the matched element for use with click/fill tools.
The tool runs the session event loop between selector checks, so
dynamically-created elements are found as they appear from JS execution
or network responses.
When running mcp server, it initialized lp.mcp.Server in the main thread
which also implicitly created the V8 isolate in the main thread.
When processing requests (like calling the goto tool) inside mcpThread,
V8 would assert that the isolate doesn't match the current thread.
Fixes#1938
When a timer is cleared, e.g. clearInterval, we flag the task are deleted and
maintain the entry in window._timers. When run, the task is ignored and deleted
from _timers.
This can result in prematurely rejecting timers due to `TooManyTimeout`. One
pattern I've seen is a RAF associated with an element where the RAF is cleared
(cancelAnimationFrame) if already registered. This can quickly result in
TooManyTimers.
This commit removes the timer from _timers as soon as it's canceled. It doesn't
fully eliminate the chance of TooManyTimeout, but it does reduce it.
The Context's call_arena should be based on the source, e.g. the IsolateWorld
or the Page, not always the page. There's no rule that says all Contexts have
to be a subset of the Page, and thus some might live longer and by doing so
outlive the page_arena.
Also, on context cleanup, isolate worlds now cleanup their identity.
dispatchStartupCommand hard-codes "TID-STARTUP" as the frame ID in
Page.getFrameTree. When a driver connects via connectOverCDP after a
real page already exists, subsequent lifecycle events (frameNavigated)
use the actual page frame ID. The driver's frame tracking was
initialized with "TID-STARTUP", causing a mismatch that hangs
navigation.
Check for an existing browser context with a target_id in
dispatchStartupCommand. If present, return the real frame ID and URL.
Fall back to "TID-STARTUP" only when no page exists yet.
Fixes#1800
This contribution was developed with AI assistance (Claude Code + Codex).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
detachFromTarget and setAutoAttach(false) both null bc.session_id
without notifying the client. Per the CDP spec, detaching a session
must fire a Target.detachedFromTarget event so the driver stops
sending messages on the stale session ID.
Capture the session_id before nulling it and fire the event in both
code paths. Add tests covering the event emission and the no-session
edge case.
Fixes#1819
This contribution was developed with AI assistance (Claude Code + Codex).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Small tweaks to https://github.com/lightpanda-io/browser/pull/1896
Improve the wait ergonomics with an Option with default parameter. Revert
page pointer logic to original (don't think that change was necessary).
