Repository navigation
A long capture succeeded, then the popup reported it failed - #67
Open
vhladiienko wants to merge 1 commit into
Open
vhladiienko wants to merge 1 commit into
vhladiienko wants to merge 1 commit into
Conversation
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.
Summary
The capture response to the popup carried every output PNG as full-size base64 data URLs. Chromium caps extension messages at ~64MiB (serialized length, so base64 costs 4 bytes per 3 raw bytes), and a long page's capture crossed it — so the response died after the capture had already succeeded. The popup showed
Error: Message exceeded maximum allowed size of 64MiB.and a blank preview over a healthy capture: the bytes were already in blob-store, which is why Save PNG, PDF export, history and the editor (all blob-store readers) kept working.The response now carries a small thumbnail instead — the first output image re-encoded at 320px wide through shot-core's existing
cropAndEncode, a few KB that cannot reach the cap. Full-size bytes stay in blob-store, exactly where everything that needs them already reads them.The popup uses the response image in exactly one place — the preview
<img>— so the thumbnail covers all of its consumption. Split captures change nothing semantically: the preview always showed the first image only; before, it also shipped every part's bytes, which is precisely what overflowed.Evidence
#preview, whilesavePngsfrom the same state saved every file fine.Full runs on this branch:
npm run typecheck✓,npm test✓ (13 files, 110 tests). The e2e suite was not run for this change; no spec asserts on the popup response shape (pngDataUrlsappeared only in the three response sites,types.ts, and the popup preview).Merge Danger
Door: two-way — reverting the single commit restores the old response shape exactly.
Blast Radius: small — the popup response and the popup's preview read; blob-store, history, editor handoff and PDF paths untouched. Merges cleanly with #66 (both touch
popup.ts; verified with merge-tree, regions are disjoint).