sz-chrome-remote-cdp.git/src/domains/fill-engine.ts, branch masterpi-browser-harness, patched to drive a Chrome on another host over CDP, with castle_cdp_search web search
https://git.soarez.net/sz/sz-chrome-remote-cdp.git/atom?h=master2026-08-02T13:42:46+00:00style: drop the comments added by the bug-audit fixes2026-08-02T13:42:46+00:00amankumarsingh77amankumarsingh7702@gmail.com2026-07-28T14:31:05+00:00urn:sha1:758be304747974f84418f66efa4353362ac1edcf
The audit fixes were required to add no comments; two doc blocks slipped through
review. Removed, leaving only comments that predate this task.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
fix(domains): one fill engine, so browser_fill stops lying about checkboxes2026-08-02T13:42:46+00:00amankumarsingh77amankumarsingh7702@gmail.com2026-07-28T14:25:53+00:00urn:sha1:cfa1892e17e3696da004c71a4942d5b12186b12c
browser_fill and browser_fill_form carried separate in-page implementations that
disagreed on the same element. The worst case was silent: browser_fill on a
checkbox fired the HTMLInputElement value setter, which writes the submit value
and leaves `checked` alone, then reported status ok — a no-op the agent had no
reason to doubt. Both tools now share one engine, with browser_fill's documented
<select> rejection kept as an explicit pre-check and per-tool focus behaviour kept
as a parameter.
Deliberate, user-approved behaviour changes:
- browser_fill on a DISABLED input now returns an error instead of success. The
old success was the bug; browser_fill_form already refused it.
- browser_fill on a checkbox/radio now toggles `checked` instead of the value.
- browser_fill_form on a contenteditable now uses execCommand("insertText"),
so it drives ProseMirror/Slack-style editors as browser_fill already did.
browser_fill keeps appending interactiveDiff and republishing refs; fill_form
still does not.
Report: docs/superpowers/reports/2026-07-26-bug-audit.md#f5
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>