fix(web): unpin preview dragging on narrow chat canvases

[MatthewFeroz]

Problem

A floating preview cannot move horizontally when the chat canvas is too narrow to fit both the reserved readable chat lane and the preview. With a 1000px canvas and a 320px preview, the lane requires x ≥ 672 while the right edge requires x ≤ 668. Every drag clamps to x=668. At 1004px the interval has zero width and dragging is still pinned.

The reserved lane arrived in #2829 at de34391427, October 2, 2026 at 12:22 PM PDT. Source comparison with the preceding revision 024d49520e, from 12:04 PM PDT, shows the earlier canvas/composer clamp allowed this horizontal movement. The recording below compares the original current layout with this fix.

To reproduce, float a browser preview or device over chat, make the available chat canvas 1000px wide, set a 320px preview above the composer, and drag its small top-right dot left by 300px. The original preview stays at x=668; the fixed preview reaches x=368.

Change

Reserve the readable chat lane only when it leaves a nonzero horizontal drag range. Otherwise use the existing canvas-edge minimum. Composer exclusion, aspect ratio, thread-details placement, resizing, and the readable lane on wider canvases retain their existing rules.

Add regression cases at 900px, 1000px, and the exact 1004px boundary, including movement back to the starting frame. Update narrow-layout expectations and retain the wider-canvas lane assertion.

Scope and approval

Submitted under the very small, focused obvious-bug exception in CONTRIBUTING.md. The defect is a degenerate drag range in an established draggable control. This patch only relaxes the lane when no horizontal movement is possible; it preserves the lane wherever a usable interval exists.

The maintainer triage of #14929 identifies the readable lane and chat reflow as intentional design. Discussion #14935 proposes restoring free-floating defaults and optional docking, without approval yet. Neither is claimed as approval for this PR. The patch does not implement that proposal, change toolbar hit targets, or alter native pointer capture. The broader open #15499 is related background.

One geometry fix covers browser and device mini-players through their shared web shell. Desktop wraps that web UI; native React Native mobile layout is unaffected. No provider, server, transport contract, or connection-mode changes are needed. There are no settings or command-palette entry points for this geometry rule, and no documentation workflow changes.

Verification

• Ran the three new drag cases against the original implementation: all three failed at the pinned x coordinate. Restored the fix and ran vp test run apps/web/src/components/chat/chatCanvasLayout.test.ts apps/web/src/components/preview/previewMiniPlayerLayout.test.ts apps/web/src/previewMiniPlayerStore.test.ts apps/web/src/components/chat/threadDetailsCardLayout.test.ts: 4 files, 75 tests passed. These cover return movement, the wide-canvas lane, composer avoidance, aspect ratios, resizing, and details-card placement.
• vp lint apps/web/src/components/chat/chatCanvasLayout.ts apps/web/src/components/chat/chatCanvasLayout.test.ts and vp fmt --check on those same files passed. vp run typecheck from apps/web passed, including after updating to main d60a71ef6e.
• Recorded the actual T3 Code dev web client on macOS at localhost:6973, using isolated worktree state and an empty thread. Both recordings use a 1000px canvas, a 320×200 preview at x=668/y=330, and the same 300px leftward gesture. Original result: x=668 → 668. Fixed result: x=668 → 368.
• Evidence uses synthetic PointerEvents through the actual mini-player component/store/layout, bypasses native pointer capture, and inserts simple test content into BrowserSurfaceSlot. The canvas width is constrained in the page for repeatability. The screenshots and recording prove the responsive layout regression; native mouse ergonomics, Electron webview boundaries, a native device stream, remote/relay connections, and the installed desktop app were not tested by this footage. The shared geometry and device aspect-ratio paths have focused test coverage.

Original layout after dragging left	Fixed layout after the same drag

Short before/after video. These are actual captured frames, with labels and a blue indicator for the scripted pointer. Assets are hosted in a clearly identified evidence prerelease in my fork and are not committed to this PR.

Model: GPT-6.1-Sol. Harness: Codex in T3 Code.

October 4 branch update

Merged upstream main at eac52f0087d9ba5dee5542f24788d1482affae43 into this branch without rewriting its history. Updated head: b5655bf086065d644decb08b6c57a40443ec5873.

• Focused regression run: Tests 75 passed (75).
• Scoped typechecks passed for @t3tools/web. Targeted lint passed; formatting and whitespace checks passed.
• The merged source tree matches the locally validated tree. Existing screenshots and recordings document the original affected flow; this branch refresh was checked by command line. Platform-specific skips are preserved, and no new native UI verification is claimed.

Branch update validated with GPT-6.1 Sol through the Codex harness in T3 Code.

[macroscopeapp]

Approvability

Verdict: Approved at 03db730

Macroscope's review found this PR approvable — This is a narrowly scoped geometry bug fix that restores preview dragging only when the existing readable-chat constraint leaves no usable horizontal range. Wider-canvas behavior and resize constraints remain unchanged, and boundary regression tests cover the affected layouts.

No code changes detected at b5655bf. Prior analysis still applies.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: pingdotgg/t3code/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 263ca291-c697-4bef-9058-8c3587bd2d59

📥 Commits

Reviewing files that changed from the base of the PR and between d60a71e and 03db730.

📒 Files selected for processing (2)

• apps/web/src/components/chat/chatCanvasLayout.test.ts
• apps/web/src/components/chat/chatCanvasLayout.ts

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

---

📝 Walkthrough

Walkthrough

The chat canvas layout changes the minimum horizontal position for preview frames based on canvas width and the last interaction. Tests cover drag movement and frame positions on narrow and large canvases.

Changes

Chat preview drag bounds

Layer / File(s)	Summary
Preview drag bounds apps/web/src/components/chat/chatCanvasLayout.ts, apps/web/src/components/chat/chatCanvasLayout.test.ts	The layout allows the preview frame to move to GAP after a resize or when the canvas cannot fit the padded minimum chat lane, preview frame, and two gaps. Tests cover dragging across 900-, 1000-, and 1004-pixel canvases and update expected frame positions.

Priority: ⬇️ Low

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

Change: Bug fix

Suggested reviewers: t3dotgg

Merge Risk: ⚪ Minimal · up to 03db7

The preview can now be dragged on narrow canvases while remaining within the canvas; overlaying chat is an allowed behavior. No merge-blocking risk was identified.

Architecture Summary

Architecture risk: 🔵 Low · up to 03db7

The change affects 1 system.

Changed systems: apps/web

Architecture concerns
No architecture-level concerns identified.

Review details

Systems and components

• observed — apps/web (ui) was modified; 2 changed files map to changed impact.

Before / after behavior

• observed — Modified behavior in apps/web/src/components/chat/chatCanvasLayout.test.ts: Adds parameterized tests for 900-, 1000-, and 1004-pixel canvases, asserting that dragging a preview 300 pixels left and then back to its starting position produces the corresponding frame positions.
• observed — Modified behavior in apps/web/src/components/chat/chatCanvasLayout.test.ts: Updates the narrow-canvas dragged-preview expectation from x=668 to x=12.
• observed — Modified behavior in apps/web/src/components/chat/chatCanvasLayout.test.ts: Updates the large-preview frame expectation from x=272 to x=12; the expected y-coordinate and dimensions remain unchanged.
• observed — Modified behavior in apps/web/src/components/chat/chatCanvasLayout.ts: The minimum preview X position is now GAP after a resize or when the container is too narrow to fit the padded minimum chat lane, preview frame, and two gaps; previously only resizing used GAP, while all other interactions reserved the readable chat lane.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 2 files.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely identifies the main change: allowing preview dragging on narrow chat canvases.
Description check	✅ Passed	The description covers the problem and reproduction steps, the change and scope, the approval exception, and focused verification results with limitations and UI evidence.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

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

---

_{Comment @coderabbitai help to get the list of available commands.}

[NikitaMGrimm]

Note

🤖 gpt-6.1-sol responding on behalf of NikitaMGrimm

I’m seeing what looks like this bug with the sidebar open: the floating preview stays locked at one x position, while dragging vertically still works. Alternating corner resizes gradually moves it into the middle of the chat, where dragging cannot take it.

Sharing this as another reproduction of the bug.