[shawnmcclelland]

PNG and PDF exports could change a frame’s layout during capture: horizontal overflow widened the rendering viewport, responsive images lost their source density, and short content was stretched to fill the frame. PDF also measured page dimensions separately from the captured image; a 1200×600 capture could be stretched onto a 1200×1000 page.

Keep the live layout viewport separate from capture bounds, preserve the full frame with transparent padding, and retain image density through resource inlining and runtime snapshots. PDF now uses logical dimensions returned with the same capture. Embedded image validation still enforces the existing resource and pixel limits.

Validation:

• Real Chromium regressions fail before the repairs and pass afterward, asserting exported pixel geometry, source selection, delayed image readiness, and responsive runtime snapshots.
• 44 actual PNG/PDF downloads replayed through production commands and the native renderer; decoded PNGs and rendered PDFs preserve frame size and image proportions.
• An actual eight-page all-screens PDF preserves mixed frame dimensions and round geometry.
• Design and bridge typechecks, modified-file formatting, and both i18n guards pass.

Beta verification is pending deployment.

[github-actions]

Here's a visual recap of what changed:

Open the full interactive recap

[shawnmcclelland]

The latest review body repeats the picture-source finding already dispositioned in the inline thread. serializeRuntimeLayerSnapshot removes every cloned source element during its sanitizer pass before resource inlining. Commit e76289c adds a real wide-to-narrow viewport regression: the runtime snapshot contains zero picture/source elements, and native export retains the selected red image rather than the blue alternate. The 19 direct/recovered fidelity cases, TypeScript, and formatting pass. No production change is needed for this repeated finding; the inline thread remains resolved.

[shawnmcclelland]

Disposition for the latest incremental review: it reports no new confirmed issue. The repeated picture-source allegation remains a false positive, with the sanitizer and real viewport-switch regression evidence recorded in #8131 (comment). The selected image remains correct in direct and recovered exports, and the associated thread is resolved; no further production change is warranted.

[builder-io-integration]

Builder reviewed your changes and has a few items to flag 🟡

Review Details

Incremental review of PR #8131 at the latest head (standard risk). The update narrows snapshot refreshes for ordinary images by comparing their source with the last successful snapshot, but the listener still schedules unconditionally for responsive images via isResponsiveExportImage(image). That means repeated responsive-image load events can continue to rerun image preparation and full snapshot serialization; the existing open performance thread covers this behavior, so I have not reposted it. The offscreen-lazy snapshot fix and the export geometry remain intact. Other agent observations about empty/broken image decoding overlap the renderer's existing broken-resource rejection and are not new regressions. No additional confirmed issues were found. 🧪 Browser testing: Skipped — browser-test-planner agent is unavailable; review was code-based.

[shawnmcclelland]

Disposition for the latest incremental review: responsive-image load refreshes are intentional. The selected density and CSSOM natural width can change while currentSrc stays the same, and export normalization needs that updated state. The source-fingerprint skip therefore applies to ordinary image loads already represented by a complete snapshot; responsive events and errors still refresh. The 19 browser fidelity cases cover density, width-described sources, picture selection, lazy loading, and recovered snapshots. Further reuse across responsive snapshots would need broader invalidation work; it is outside this MVP, and the review reports no additional confirmed issue.