- `available_providers` holds the static enum tag names; drop the dupe
loop, its errdefer and the per-string frees.
- `reconcileModel` returns `error.ModelNotAvailable` directly instead of
a `use`/`abort` union the caller only mapped to that same error.
- `runCommand`/`printCommandResult` take `Command.ToolCall`; the caller
already has it, so the unreachable "no tool mapping" branches go.
- `handleSave` reuses `rememberSavePath`, which now propagates its
allocation failure so a first save under OOM warns instead of
unwrapping a null `save_path`.
- `SlashCommand.all_names` is a comptime `++` of the three name lists.
- `buildUserMessageParts` reads the attachment once for both text and
image, and prepends the text part instead of copying the list.
- `printSeverity`/`formatBulletLine` use `allocPrint` and the shared
`emitStderr`; drop an unreachable `ends_ws` check in `renderMetaHint`.
In a REPL whose stderr isn't a tty the spinner is disabled, so
`agentToolDone`'s `emitAbove` returned false and the `● [tool: …]` line
was discarded. `printToolOutcome` already fell back to a raw stderr write
in that case; share that fallback through `emitStderr`.
The non-REPL result line sliced `text` at a byte offset, which could
split a multi-byte codepoint and emit garbage. Truncate on a UTF-8
boundary instead.
Each optional block after the pass count (slowest list, metrics JSON,
failed-test summary) now prints its own leading separator instead of the
previous block printing a trailing one, so the output never ends with an
empty line. Printer.status places the color reset before a trailing
newline so the escape sequence no longer opens the next line.
The Zig 0.16 port of SlowTracker.endTiming dropped the early return for
unnamed tests and discarded the flag, so the refAllDecls blocks were
timed and queued like real tests. With a filter that matches nothing they
were the only candidates and filled the "Slowest 5 tests" output.
Every key path resolves its target through user_input.focusedElement,
which is document.activeElement with the <body> fallback. WebDriver and
the MCP press action used to fall back to the document node instead, a
target no default action or char step handles.
The Enter and Space activation rules share isButton, and the text-entry
rule (no text goes into a checkbox or radio) lives on the TextEntry
mixin as acceptsTextEntry rather than as a type test inside the shared
insertion helper. pressKey takes its extra ref only when a keypress will
be built from the keydown.
Chrome clicks a button on the keypress Enter produces, after the keypress
fires; only links follow Enter on the keydown. Clicking on the keydown put
the click before the keypress and, with the char step also submitting for
button-type inputs, submitted the form twice.
The MCP press action relied on the same char step for Enter, so its own
implicit submission is gone with the double submit it caused on buttons.
The #3549 test only covered LP.getSemanticTree's text format. Cover
the JSON format with interactiveOnly on the same fixture, and drive the
MCP tree and nodeDetails tools through call() with a child-frame
backendNodeId. Passing the main frame in either tool now fails the
suite instead of only tripping a debug assert.
Every caller resolved node.ownerFrame(frame) before building a
SemanticTree or calling getNodeDetails, and every one made the same
decision on a frameless node. Move that into SemanticTree.init, which
returns error.FramelessNode, and turn getNodeDetails into a method so
it goes through the same constructor.
With init as the only entry point the per-method assertOwns is
redundant, so drop it along with its copy of StyleManager's helper.
A nodeId root inside a child frame was walked with the main frame. The
style checks already resolve the owner frame per element, but the
listener map was built from the main frame's event manager, so
listener-only elements in the iframe were reported non-interactive, and
relative hrefs resolved against the parent's base URL.
Resolve the root's owner frame before the walk, as getSemanticTree and
getNodeDetails do.
Follow Chrome's model. A keydown only runs its own default action (Tab,
caret moves, Backspace, Enter activation). Text is typed by the char half
of the press, which fires keypress and then beforeinput/textInput, so
either can veto the edit.
A keyDown carrying `text` runs the char step inline (Puppeteer,
Playwright). A text-less keyDown followed by a `char` message runs it on
the char (chromedp), so each character is typed once. A cancelled
text-less keyDown drops the char that follows it, as Chrome does.
BiDi, WebDriver and the MCP press action go through the same pressKey,
deriving the text from the key. pressKey holds a ref on the keydown for
the keypress it builds, so nothing reads the event after dispatch.
Input.insertText fires beforeinput like a key press does.
Applies the frame-ownership pass to SemanticTree, copying what we did for
StyleManager (1). SemanticTree doesn't visit iframes, so the frame of the root
is the frame/frame._style_manager we need to target for all visited nodes.
Like #3536, it's up to the callers to (a) get the correct frame and (b) decide
what to do on a frameless-node.
(1) https://github.com/lightpanda-io/browser/pull/3536
TIL: foster parenting is apparently something that happens when a non-table
child element is placed inside of a table, e.g.
<table><img src...></table>
Apparently, this was common enough that it requires special handling. html5ever
goes through a different path (_appendBeforeSiblingCallback) which would skip
our previous parseInserted.
The image src can now come from a srcset, including the source of a picture.
The (simple) Parser is all Claude.
There's some similarity here with the recently changed Select<->Option (1)
code in that, changes to a child (source/option) need impact their parent (
picture/select).
(1) https://github.com/lightpanda-io/browser/pull/3502
Currently, our waitForImport blocks the caller, but continues to process any
already-queued requests. This can result in new JavaScript running while v8
is linking modules and that JavaScript can itself import a module that is
part of the still-being-linked graph.
waitForImport now works like a syncRequest. While HttpClient will continue to
make progress on all transfers, all other transfers will gate behind the waiting
one (using the same infrastructure that exists for syncRequest).
This crash was seen on an unknown srape URL.
The two low-level trusted-event dispatchers took button (which button changed)
and buttons (the held mask) as adjacent, swappable positional args. Bundle the
shared event fields into a PointerInput struct with named fields, mirroring the
file's HoverContext, so a transposition is a field name rather than a silent bug.
Fold the two loose Page fields (input_pressed_buttons, input_mousedown_suppressed)
into a PointerButtons struct in user_input.zig that owns the chord mask and the
press/release transitions, so triggerMousePress/Release keep only dispatch.
Add runMouseDownFocus so the three click callers stop repeating the
!suppress_mouse and !suppress_focus gate; a focus-error policy param keeps each
caller's warn-vs-propagate behavior.
Trim the verbose dispatch/trigger and CDP-test comments to a single sentence
each, moving behavior contracts onto the function doc-comments; also drop the
stale buttonsMask comment orphaned by the earlier buttonsBitmask reuse.
Round-1 review feedback from arrufat on #3507 (share pointer/mouse click
dispatch across click paths):
- CDP mousePressed now threads clickCount into mousedown's detail
(mouse_detail), matching the MCP path (actions.click) instead of
always firing detail 0. Threaded through BiDi's press call too, which
was already tracking click_count for release but silently dropping it
on press.
- dispatchClickAsPointer now carries the still-held buttons mask instead
of hardcoding 0, so a primary click firing mid-chord (the primary
button releasing while another button is still held) reports the
correct PointerEvent.buttons.
- Fixed a regression caught while verifying the above against live
Chrome: the first fix's fallback forced clickCount 0 (CDP's default
when the field is omitted) to detail 1. Chrome and Firefox both
preserve 0 there, and Chrome doesn't fire `click` at all in that case
— the fallback now preserves 0 instead of forcing 1.
Left two pre-existing issues alone, flagged in code comments instead of
fixed, per arrufat's own scoping:
- triggerMouseRelease's parallel clickCount-0 fallback has the same
mismatch on the release side; not introduced by this PR.
- The chord's activation-event ordering (contextmenu on the right press
vs. this codebase's release-only contextmenu, and no auxclick) is a
real, pre-existing deviation from both Chrome and Firefox, confirmed
on Firefox too during this round, not Chrome-specific.
Test coverage: a parametrized CDP test over clickCount 0/1/2 asserting
mousedown's detail; a chord test asserting a mid-chord primary click's
buttons mask. Two more tests were added independently during review
audit and kept as-is: clickCount 2 on a press+release pair asserting
detail 2 on mousedown/mouseup/click plus dblclick, and a chorded press
asserting its own mousedown branch also carries the press message's
clickCount.
Confirmed against live Chrome (headless, raw CDP) and Firefox (headless,
WebDriver BiDi) for both the mousedown-detail and chord-buttons fixes.
zig fmt --check clean; cdp.input 20/20 and bidi.input 5/5 pass.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A second independent Codex audit on the rebased bdabfea42 found a real
regression the chord fix itself introduced: the chorded-press branch in
triggerMousePress dispatched the compatibility mousedown but discarded its
cancellation result and never called focusForMouseDown, unlike the
first-button path. Pressing a second button on a different element while
the first is still held (e.g. right-click a second field while holding
left on the first) left focus on the original element instead of moving
it to the new mousedown's target, diverging from real Chrome.
Independently verified before committing:
- Traced the diff: the chorded branch's `_ = try dispatchMouseEventOn(...)`
discarded the return value entirely, so suppress_focus was never
computed and focusForMouseDown was never reachable from that branch —
confirmed this matches the first-button path's own
`if (!press.suppress_mouse and !press.suppress_focus) try
focusForMouseDown(...)` structure, which the chord branch should mirror
but didn't.
- Reverted the one-line fix (kept the new test staged) and confirmed the
new "chorded mousedown focuses its target unless pointerdown or
mousedown was cancelled" test fails against the pre-fix code, then
restored it.
- Ran the full suite: zig build test and -Dwpt_extensions both 1521/1521.
- Rebuilt the binary and ran the extended tools/shared-click-audit.mjs
--assert-chord --assert-chord-focus against it: chord_focus_contract
PASS, with the raw event trace confirming focus actually landed on the
second element ("ticket").
- Ran the same harness with --chrome: chord_focus_contract PASS against
real Chrome too, independently confirming this is the correct target
behavior and not just the audit's claim.
Fix mirrors the existing first-button path exactly: capture the chorded
mousedown's own cancellation result and run focusForMouseDown when it
wasn't cancelled, still gated by the gesture-level suppression flag so a
cancelled initiating pointerdown still suppresses every mousedown in the
chord, as before.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XLXnBHBxQNskg2MAke3Lhv
Adrià Arrufat