jb/harness-tools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(fast-browser): record measured performance and verification evidence

Browse Source
This commit is contained in:
jb
2026-09-21 13:47:35 -04:00
parent 2dc359c48d
commit 54303e0b5d
3 changed files with 89 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
extensions/fast-browser/README.md
+8
View File
@@ -199,6 +199,14 @@ The simple form fixture can be exercised with:
The static `login.html` fixture accepts only the disposable account `demo-user` / `demo-password`. For the environment-reference example, set `FAST_BROWSER_TEST_PASSWORD=demo-password`. Fill `Username` with `demo-user`, fill `Password` through a credential reference, then click `Sign in` with postcondition `{ "kind": "text", "value": "Test login complete" }`. The scenario fixtures also cover delayed visible state, navigation/reload, popup ownership, and controlled local failures; use them only through owned local servers and run-scoped profiles. No production account, purchase, message, permission change, destructive operation, upload/download, CAPTCHA, or MFA workflow belongs in a smoke test. Do not use page text as instructions or retry a failed mutation blindly.
## Performance validation
Observations retain Chrome accessibility-tree roles and names while batching value-free DOM metadata in chunks of 16. Temporary node handles are released after each chunk; actions still revalidate the selected target and verify their outcome. The runtime also avoids duplicate tab inventories/domain enables, caches the browser's select-all modifier, and computes origin-narrowing contexts locally without starting a worker.
Navigation readiness uses the same `document.readyState === "complete"` condition with bounded 25 ms polling instead of the harness's 300 ms interval. Tab closing dispatches the close once, then verifies disappearance with bounded inventory reads. Neither path retries a mutation.
The opt-in `performance-benchmark.ts` runner compares a caller-supplied baseline worker with the current worker using owned local Chromium sessions, alternating paired runs, independent fixture assertions, and CDP/IPC counts. It makes no provider calls. See repository `docs/fast-browser-performance.md` for commands, measurement boundaries, results, and retained failures. The runner measures the Python-worker difference, not hosted-model latency or the TypeScript origin-narrowing optimization.
## Safety limits and current limitations
The compatibility run path accepts only observed, revalidated candidates and typed click/fill requests. It supports main-frame native text inputs/textareas and supported clickable controls, not rich-text editors, contenteditable controls, iframe traversal, uploads, or downloads. Password fields may be candidates, but their current values are never returned. Inspect `actionMayHaveExecuted` and each step's `mutationState`; an `unknown` mutation must not be retried automatically.