fix(agent-browser): route oversized tabs snapshots to the tab list - #297
Merged
Conversation
A stream message longer than FRAME_PULSE_THRESHOLD (16384) was treated unconditionally as a frame, so a `tabs` snapshot with many long URLs/titles that crossed the threshold was silently dropped — the tab list never updated. Discriminate by content, not just size: a base64 JPEG frame body contains no ` or : characters, so a compact "type":"tabs"/"type":"status" substring is a zero-false-positive marker for an oversized control message. Only those pay a parse; frames keep their hash+pulse fast path untouched. Closes #296
Deploying mouseterm with
|
| Latest commit: |
0f3b5a6
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://14cda9f4.mouseterm.pages.dev |
| Branch Preview URL: | https://fix-issue-296.mouseterm.pages.dev |
This was referenced Jul 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Closes #296. In
agent-browser-connection.ts,handleMessagerouted stream messages purely by size: any payload longer thanFRAME_PULSE_THRESHOLD(16384) was treated as a frame. Atabssnapshot carriesurl+titleper tab, so a user with many open tabs (long URLs/titles) can push atabsmessage past 16KB. When that happened the snapshot was silently dropped — hashed and emitted as a bareframe-pulse— and the tab list / active-tab selection never updated. Because the daemon re-broadcasts tabs on its heartbeat, a consistently-oversized tab list would appear frozen until a smaller snapshot happened to arrive.The idle path (
wantFrameData()false) is the dominant real-world case:wantsProvisionalFrame()returns false at steady state on hosts with crisp screenshots, so the fix had to cover it — not just the hover path.Solution
Discriminate by content, not just size. A frame's bulk is a base64 JPEG body, and the base64 alphabet contains no
"or:, so a compact"type":"tabs"/"type":"status"substring can never occur inside a real frame. It's a zero-false-positive marker for an oversized control message:dispatchControlhelper).wantFrameData()).This preserves the threshold's performance intent — frames never pay an extra parse, only rare oversized control messages do — and the change is strictly monotonic: it can only recover a previously-dropped snapshot, never misroute a frame.
One assumption: control messages are serialized as compact JSON (no space after the colon), which every in-repo fixture and
JSON.stringify's default output confirm. If a daemon ever emitted spaced JSON, this fix would be a no-op for that case rather than a regression.Testing
Added a regression test in the existing
agent-browser-connection.test.tsthat emits an ~24KBtabssnapshot (80 tabs with long URLs) on the default idle path and asserts the 80 tabs reach the snapshot. It fails onmain([]— dropped) and passes with the fix. Full file suite (8 tests) green;tsc --noEmiton the lib clean.Closes #296 — automated triage