Repository navigation
[Bug]: Three competing controls are jammed together at the chat/preview boundary #6273
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- Open a thread with enough chat history for the vertical scrollbar to appear.
- Open Browser in the right-side panel.
- Switch the browser preview to a fixed/responsive viewport so the preview-content resize grab is visible.
- Move the pointer along the boundary between the chat and preview.
- Try to use each of these independently: the chat scrollbar, the side-panel width resize grab, and the preview-content resize grab.
Expected behavior
Each interaction should have a distinct and reliable pointer target. The chat scrollbar should remain usable, and resizing the side panel should be clearly distinguishable from resizing the browser preview content.
Actual behavior
Three separate, full-height interaction targets are packed into essentially the same narrow boundary:
- Chat-window scrollbar
- Side-panel resize grab
- Preview-content resize grab
They are difficult to distinguish and target independently. Attempting to use one can hit an adjacent control instead.
CHAT WINDOW SIDE PREVIEW PANEL
PREVIEW CONTENT
boundary
│
chat content ……… [ S ][ P ][ V ] ……… preview
│ │ │
│ │ └─ preview-content resize grab
│ └────── side-panel resize grab
└─────────── chat scrollbar
S, P, and V are three narrow, full-height interaction targets
occupying essentially the same boundary.
Impact
Minor bug or occasional failure
Version or commit
T3 Code Alpha 0.0.33
Environment
Windows desktop app, T3 Code Alpha 0.0.33
Logs or stack traces
Screenshots, recordings, or supporting files
e14c94da3bcbb7374a31aa79b3a3d824.mp4
Workaround
No response
Activity
maria-rcks commentedon Oct 12, 2026
Note
This is an automated response from a bot acting on maria's behalf.
This issue has had no activity since 2026-08-12.
Is it still relevant on the current version? If so, your version and OS would help.
yiliangs commentedon Oct 30, 2026
@juliusmarminge Thanks for checking. It still happens on the current Windows release.
I think the Linux web run missed it because the preview-content resize rails only render in the Electron hosted-webview path. The web dev server never mounts them, so that path has two controls at the boundary rather than three.
Environment: T3 Code 0.1.5, Windows 11 (build 26200), display scaling 150%, app zoom 100%. Thread with enough history to scroll, Browser panel at example.com, device toolbar on, Responsive preset.
Measured from the DOM, in CSS px:
The separator overlaps the last 3 px of the scrollbar and the first 4 px of the viewport rail, so three full-height targets share 23 px and the middle one takes hits meant for either neighbor.
To be clear, nothing is malfunctioning. Each control does what it is coded to do. This is a layout decision about how much room the three targets get, and whether it is worth changing is your call.