[Bug]: Zooming out shrinks the fullscreen visualization viewport instead of showing more content #30551

Closed at the reporter's request: an existing open fix already covers this behavior — PR #29350.

Before submitting

• I searched existing issues and did not find a duplicate issue for this specific behavior.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop — shared web fullscreen HTML visualization viewer (apps/web).

Steps to reproduce

Reporter-observed workflow; not independently replayed during this investigation:

1. Open a generated HTML visualization/diagram in a conversation.
2. Expand it into the large preview with the title and minus / percentage / plus controls below it.
3. Press Zoom out from 100% to 75%, then 50%.
4. Observe the content area and whether more of the diagram becomes visible.

Use a diagram larger than the initial iframe viewport so that clipping is easy to see. These are the visualization viewer's own controls, rather than the application's overall zoom shortcuts.

Expected behavior

Zooming out should reduce the content scale within the available preview area, letting the user see more of the diagram. The usable viewing area should continue to fill the dialog.

Actual behavior

Zooming out makes the displayed frame take up less screen space instead of exposing more of the diagram. Content stays clipped, with large unused areas below and to the right.

The reporter's screenshot shows 50% zoom: the diagram occupies the upper-left portion of the large dialog and is cut off across its lower edge, while the rest of the dialog is largely empty.

Impact

Minor bug or occasional failure.

The existing zoom-out control does not help inspect the full diagram, even though ample space is available.

Version or commit

Exact build used for the reporter's screenshot is unconfirmed.

The locally installed macOS Nightly app currently reports 0.1.7-nightly.20261103.4138; this is environment metadata, not confirmation of the screenshot's build.

Source inspected at a185dd924889cd7f925760431a9f29b973a35e2f. Fetching the same file from current main during filing returned identical file content.

Environment

T3 Code desktop on macOS. Exact OS version and display scaling for the screenshot were not recorded.

Logs or stack traces

No runtime logs collected. Investigation used the user's screenshot/report and source inspection; no independent interactive reproduction or new tests were run.

Screenshots, recordings, or supporting files

The original screenshot was reviewed locally and has not been uploaded publicly.

Existing public before/after screenshots and recordings for the matching defect are available in PR #29350. Those are that PR's evidence, not new captures from this report.

Supporting code investigation

HtmlRenderDialog.tsx gives the inner wrapper fixed 100cqw × 100cqh layout dimensions and applies style={{ zoom }}. Its HtmlRenderDocument fills that wrapper with size-full.

Consequently the iframe's visible viewport is scaled along with its content. At 50%, it occupies half the available width and height; its layout viewport has not grown to expose more content. This is consistent with the screenshot and reported behavior. The 50% lower limit and 25% button increments also match the controls in the screenshot.

PR #29350 is already open and proposes compensating wrapper width and height by 1 / zoom to preserve the visible frame size. Linking it here to avoid parallel implementation. PR #22349 is also referenced there as overlapping work.

Related issues checked: #26611 concerns scroll-versus-zoom input in image/Mermaid previews; #29740 concerns tall raster images and their zoom cap. Neither describes this HTML iframe viewport-sizing defect.

Workaround

No workaround verified during this investigation.

Prepared from the user's report and screenshot, with source investigation by GPT-6.1 Sol through the Codex harness in T3 Code.