[Zeus-Deus]

Problem

Opening an html_render page full screen made it hard to read. The page was written for the 728px reply column, but the dialog stretched it across 92vw (about 1700px on a typical display). Paragraphs became single long lines, and vw-sized type roughly doubled. The frame was always 86vh tall: a short page sat in an empty card, and a long one scrolled inside the iframe, where the injected CSS hides the scrollbar. Zoom used CSS zoom, which never changes the page's layout width. At 150% the page ran off the right and bottom edges with two nested scroll areas, and at 50% it shrank into a corner.

Change

All changes are in HtmlRenderDialog:

• Width: the card is capped at min(92vw, 1176px), a 1144px page plus padding. That's the widest width the server measures a page at, so a page stays close to the layout it was written for.
• Height: the frame takes the height the page already reports (onContentHeight). Before the first report, it falls back to the server-measured heights for that width. The card's old fixed height becomes its max-height, so short pages get a short card and tall ones scroll the card, never the iframe.
• Zoom: kept, but it now divides the page's layout width. At every zoom level the page reflows to fill the card instead of overflowing it or leaving empty space.

HtmlRenderFrame now passes its HtmlRenderReference to the dialog instead of just the title. Mobile uses its own WebView with native scrolling and isn't affected.

Scope and approval

A small, focused fix for an obvious bug in the existing full-screen view (#17561): the view sized pages wrongly and its zoom didn't work properly. It adds no settings, contracts, or server changes.

Verification

• vp test run src/components/chat/HtmlRenderDialog.browser.test.tsx src/components/chat/HtmlRenderFrame.browser.test.tsx (apps/web): 11/11 passed. Three new tests cover the width cap, fitting to the reported height with only the card scrolling, and zoom reflowing at 200% and 50%. Against the old dialog, all three fail: the card is 1766px wide, the frame stays 608px tall, and at 200% the page paints 2291px wide in a 1146px card.
• Targeted vp lint and vp fmt on the changed files are clean. tsc-rs --noEmit for apps/web reports no errors.
• The screenshots below are the real dialog component rendering a page wrapped with the real bootstrap, in the browser test runner at 1600×900 (a throwaway test, not committed). I didn't check it in a running app.

	Before	After
100%
150%

#19909 changes the same height class to account for the desktop titlebar. Whichever lands second needs a one-line rebase onto the new max-h.

Investigation, fix and PR text by Claude Opus 5.5 (High) in Claude Code. The diagnosis was cross-checked by GPT 6.1 Sol (Extra High) and Opus 5.5 (High) subagents through T3 Code.

🤖 Generated with Claude Code

[macroscopeapp]

🟡 Medium chat/HtmlRenderDialog.tsx:30

At fractional card widths, the dialog repeatedly re-renders while idle because each contentRect.width update replaces measureBox, whose setup writes the integer clientWidth and restarts the observer; the observer's initial notification then repeats the cycle. Round the observed width to match clientWidth so the initial notification does not trigger another render.

Suggested change

	if (entry) setWidth(entry.contentRect.width);
	if (entry) setWidth(Math.round(entry.contentRect.width));

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/chat/HtmlRenderDialog.tsx around line 30:

At fractional card widths, the dialog repeatedly re-renders while idle because each `contentRect.width` update replaces `measureBox`, whose setup writes the integer `clientWidth` and restarts the observer; the observer's initial notification then repeats the cycle. Round the observed width to match `clientWidth` so the initial notification does not trigger another render.

[macroscopeapp]

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — This focused fix changes the default fullscreen HTML presentation by introducing content-driven sizing, a width cap, and reflowing zoom for all existing users of that view. An unresolved Medium finding also reports possible idle re-rendering at fractional widths, so the change warrants human review.

Needs human approval because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

Important

Review skipped

Review was skipped as selected files did not have any reviewable changes.

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 42185a6
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: af3d253f-d51b-4c50-b7e5-6c3c3958978c

Commits

Reviewing files that changed from the base of the PR and between 708fb32 and 9f4a723.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• Trigger review

No actionable comments were generated in the recent review.

Walkthrough

The fullscreen HTML render dialog now receives render metadata and derives its title and preview dimensions from that reference. It measures popup width, uses document content-height updates, and constrains scrolling to the preview card.

Changes: HTML render dialog

Layer / File(s)	Summary
Dialog sizing and validation apps/web/src/components/chat/HtmlRenderDialog.tsx, apps/web/src/components/chat/HtmlRenderFrame.tsx, apps/web/src/components/chat/HtmlRenderDialog.browser.test.tsx	The dialog takes an htmlRender reference and derives the title from it. It sizes the preview using measured width, zoom, and document content height. The preview width is capped, and the card provides bounded scrolling. The frame passes the render reference. Browser tests check height updates, card scrolling, and zoom reflow.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Sequence Diagram(s)

sequenceDiagram
  participant HtmlRenderDialog
  participant observeResize
  participant HtmlRenderDocument
  participant PreviewCard
  HtmlRenderDialog->>observeResize: Observe preview width
  observeResize-->>HtmlRenderDialog: Report measured width
  HtmlRenderDialog->>HtmlRenderDocument: Pass content-height callback
  HtmlRenderDocument-->>HtmlRenderDialog: Report content height
  HtmlRenderDialog->>PreviewCard: Render sized preview in scrollable card

Loading

Possibly related issues

• Full-screen HTML render dialog crops content instead of scaling it down when zooming out #34055: The issue reports cropping during zoom-out in the fullscreen HTML dialog. This change reflows the page at a zoom-adjusted layout width and sizes the frame from reported content height.

Possibly related PRs

• pingdotgg/t3code#29350: Both changes modify fullscreen HtmlRenderDialog zoom behavior and preview sizing.
• pingdotgg/t3code#24581: Both changes modify the fullscreen dialog’s height constraints.
• pingdotgg/t3code#34067: Both changes modify fullscreen HTML zoom layout dimensions to support page reflow.

Suggested labels: bugfix

Suggested reviewers: bil0000

Merge Risk: Minimal · previous review 708fb

No actionable issue with the dialog change is established. It is mergeable after normal checks.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the primary change: fitting full-screen HTML pages to their content and reflowing them when zoomed. It uses a suitable conventional commit format.
Description check		The description includes all required sections: Problem, Change, Scope and approval, and Verification. It explains the defect, implementation, scope rationale, focused tests, observed results, screens…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Description check

Explanation

The description includes all required sections: Problem, Change, Scope and approval, and Verification. It explains the defect, implementation, scope rationale, focused tests, observed results, screenshots, limitations, and agent attribution.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: c82e1ba
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: e67fb2f0-1ccf-4b08-bf9c-c57e7358b27c

Commits

Reviewing files that changed from the base of the PR and between 4db31f3 and 708fb32.

Files selected for processing: 3

• apps/web/src/components/chat/HtmlRenderDialog.browser.test.tsx
• apps/web/src/components/chat/HtmlRenderDialog.tsx
• apps/web/src/components/chat/HtmlRenderFrame.tsx

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

[Gavin-Key]

This would fix what I hit. An agent showed a 16:9 slide deck in html_render (images sized by width, Prev/Next buttons below). In full screen on a 16:9 monitor at 100%, the bottom of each slide and the Prev/Next buttons are cut off, with no scrollbar to reach them. Zooming out shrinks it into the corner instead.

Windows 11 desktop.

[juliusmarminge]

Evidence

Real web client, Chromium, 1920×1080, identical synthetic pages on fresh isolated state. Open tall HTML full screen → 100% → 50% → reset → 150% → 200% → scroll card to bottom → open short page at 100%.

The scenario failed on base and passed on head. Visually, base scales into a corner or clips content; head reflows within a capped-width card, reveals bottom navigation by scrolling, and fits the short page.

State	Before — 42185a6206	After — 9f4a723e17
100%
50%
150%
200%
Scroll card to bottom
Short page
Recording	Before interaction	After interaction

Scenario and synthetic page driver

AI-assisted; verified with the tests and tools listed above.

Not shown:

• Desktop Electron shell was not run; the comparison exercised the real web client.
• HTML publication and server-side measurement were bypassed with synthetic attachments and replayed tool responses; this proof covers the full-screen rendering and zoom behavior.