[Bug]: Conversation "Message Bars" Vertical UI Overfil#15461

Triage

Thanks @RobbyV2, the screenshot made this easy to pin down. Those bars are the turn minimap: one tick per user message, drawn down the left edge of the chat. I confirmed the overflow on v0.0.45 and on current main.

What I found

• The minimap is TimelineMinimap in apps/web/src/components/chat/MessagesTimeline.tsx. The rail is centered in the timeline column and grows by 8px per message, capped only by min((count - 1) * 8px, calc(100vh - 18rem)) (resolveTimelineMinimapHeightStyle).
• That column is the area under the 52px header, and it continues behind the composer. The composer is an overlay at z-20, the minimap is z-40, and the chat column doesn't clip the overflow. Past a couple of dozen turns, the centered rail runs through the composer and up into the header.
• 100vh - 18rem isn't the visible chat height. Once the cap applies, it still leaves only about 118px of the column free, which is less than a normal composer, and the previous/next buttons hang off the ends of the rail on top of that.
• In your screenshot the ticks are still on the uncapped 8px spacing and already reach the header icons and the composer controls, so the cap doesn't keep them inside the message area.
• The rail height math hasn't changed on main since v0.0.45 (only the tick width animation did).

Likely fix area

Some options:

• Size the rail from the actual visible message area (between the header and the composer) instead of a fixed 100vh - 18rem.
• Compress the tick spacing once the turn count exceeds the available height, or switch to a scrollable or sampled rail for very long threads.
• Clip or constrain the minimap container so it can't render over the header and composer.

A maintainer will decide on the fix direction.

I'd like to work on a fix for this. Triage left the direction open, so here's what I'm proposing:

• Collapsed by default. The idle rail draws ticks at tighter spacing (4px instead of 8px) and shows at most 24 of them. Past 24 turns, each tick stands for an even slice of the thread and lights up when any turn in that slice is on screen. The idle rail stays under ~100px, so it no longer runs into the composer or header. The ticks also stay distinct instead of merging into a solid bar (#16248).
• Expands on hover or keyboard focus. Hovering or focusing the rail shows today's full rail, with one tick per turn. Previews, click-to-jump, and the prev/next buttons are unchanged. It collapses again when the pointer leaves.

The switch is an opacity crossfade between the two tick layers, so no layout is animated.

One open point: while hovered, the full rail keeps today's height cap, so in a long thread it can still reach over the composer until the pointer leaves. I can also fit it to the visible message area in the same PR if you'd prefer.

Does this direction work for you? If so, I'll open a focused PR linking here, with before/after recordings.

Update: I built this and tried it on an 80-turn thread. Where it landed:

• The rail only collapses past 20 turns, and only when the gutter shows the minimap at rest. Shorter threads look exactly like today.
• At rest it's 20 ticks at 4px spacing (76px), so it stays clear of the composer and header. Each tick lights up when any turn in its slice is on screen.
• Hovering or keyboard focus opens the full rail. The hover area switches to full size at once, so the preview and click always match the pointer. The ticks animate open with scale and opacity only, with no layout animation.
• The prev/next arrows only take the pointer once the rail is open, with a little hit slop so overshooting them doesn't close it.

Before/after screenshots and a short recording are below. The open point from my last comment still stands: while hovered, the full rail can still reach over the composer. Does this direction work for you? If so, I'll open the PR.

Before (main, 80-turn thread): the rail runs past the top of the composer.

After, at rest: 20 ticks at mid-height, clear of the composer.

After, on hover: the full rail with previews, as today.

Recording: hovering opens the rail, moving along it shows previews, and moving away collapses it.

https://github.com/user-attachments/assets/e7a08d51-0ef7-4db1-921b-3239493d4244

Tested the web dev app on Linux at main b5a226e49c, using an isolated database with 150 added user messages. Opened the conversation and used Load earlier turns until all 151 navigation marks were loaded. Checked 1280×800, 1440×1030, and 1280×600 CSS-pixel windows (light theme, DPR 2). The marks stayed below the header; I did not reproduce the overflow in the supplied screenshot. An empty thread had no marks, and the initial 10-turn window also stayed contained. No provider session was started. Linux Electron was not tested.

Does this still happen on the current release or nightly? Please include the exact version, window dimensions, display scaling/app zoom, and approximate number of user messages when it starts. A fresh whole-window screenshot would help distinguish the old header/composer overlap from dense marks within the conversation.

1440×1030:

151 loaded navigation marks at 1440×1030

1280×600:

151 loaded navigation marks at 1280×600

This is a conversation with hundreds of turns.

This is still an issue, my setup:

• KDE plasma 6
• t3 code linux v0.1.2
• 160% scale
• t3code window size is 1408.75 x 895 (logical) scaled to 2254 x 1432, my monitor resolution is 2880 x 1800