Sign up
View stargazersSign up

[Bug]: Message navigation minimap becomes a solid rectangle in very long conversations#16248

opened24d agobyLlenard-d

Before submitting

  • I searched existing issues and discussions and did not find a report of this specific symptom.
  • I included the available steps and screenshot evidence needed to investigate the problem.

Area

apps/web (message navigation minimap in the desktop app)

Steps to reproduce

  1. Open a conversation with a very large number of messages.
  2. Look at the narrow message navigation bar along the left edge of the chat. Its marks let you hover to preview individual messages.
  3. Compare it with the same bar in a shorter conversation.

The reporter observed this in an existing long conversation. The exact message count at which it starts is not known. I have not independently reproduced it in a synthetic conversation.

Expected behavior

The message marks remain visually distinct, so the user can identify individual targets for hover previews even in a very long conversation.

Actual behavior

With very many messages, the marks visually merge into an almost continuous solid vertical rectangle. The individual marks are hard to distinguish. The supplied screenshot shows this state.

This report concerns the appearance and density of the navigation marks. Whether any hover previews also fail has not been established.

Impact

Minor bug or occasional failure. The navigation bar becomes difficult to read in long conversations.

Version or commit

Installed desktop app checked on the reporter's Mac: T3 Code Nightly 0.0.46-nightly.20261004.2648. The exact version at the time the screenshot was taken was not separately confirmed.

Environment

macOS 26.6.2 (25G83), T3 Code Nightly desktop app.

Screenshots, recordings, or supporting files

The reporter's cropped screenshot shows the message navigation marks merging into a nearly continuous vertical rectangle:

Message navigation marks merge into a solid vertical rectangle in a very long conversation

Workaround

No verified workaround.

Related report

#15461 reports the same minimap overflowing vertically into the header and composer. Its report and triage comment do not describe the marks merging into a solid rectangle. This issue records that distinct symptom; maintainers can link or combine the reports if investigation shows the same cause.

JJulius Marminge24d ago

Note

Grok responding on behalf of Julius.

Triage

Thanks for the careful report and the cropped screenshot, @lenard-d! Keeping it separate from #15461 was helpful.

What I found

  • The rail is TimelineMinimap in apps/web/src/components/chat/MessagesTimeline.tsx, with one mark per user message (deriveTimelineMinimapItems).
  • resolveTimelineMinimapHeightStyle sizes the rail to (count - 1) * 8px, capped at calc(100vh - 18rem). Marks are placed by resolveTimelineMinimapTopPercent at index / (count - 1) of that height, so once the cap binds, each extra user message shrinks the spacing instead of growing the rail.
  • Idle marks are 2px tall (h-0.5) and about 8px wide. They touch when the spacing reaches 2px, roughly 450 user messages on a rail about the height of your crop, and start reading as a solid bar earlier, around 3–4px. Your screenshot matches that compressed layout. These helpers haven't changed since the minimap landed in #3587, so your Nightly and current main behave the same.
  • Hover previews use a separate path: resolveTimelineMinimapIndexFromPointer still maps the pointer to an index, so previews can open even when the marks have merged. It's the visual distinction that's lost.
  • #15461 is the same rail but a different failure: the centered rail (top-1/2 -translate-y-1/2, z-40) overflowing the message column while marks are still about 8px apart. The two interact. Shortening the rail to fix the overflow would make this merging start at a lower message count, so the two are worth considering together.

Likely fix area

Options:

  • Fit the rail to the visible message area between the header and composer instead of 100vh - 18rem (relevant to #15461).
  • Keep marks distinguishable once the rail is full, for example by sampling or clustering user messages, scrolling the rail, or enforcing a minimum spacing above 2px.

A maintainer will decide on the fix direction.

Llenard-d24d ago
Synced from GitHub

One possible fix: use a ChatGPT-style scrollable message rail.

  • Keep the spacing between marks constant as the message count grows.
  • Give the rail a fixed visible height that fits between the header and composer.
  • Once the marks exceed that height, let the rail scroll independently. Wheel or trackpad input over the rail should scroll the marks without scrolling the conversation.
  • Add a soft fade at the top and bottom when more marks are available in that direction. Marks gradually fade out as they leave the visible area and fade in as they enter it.
  • Keep the existing hover previews and click-to-message navigation.

By "fade," I mean a gradual change in opacity, not a blur. This could keep individual marks distinct at high message counts while also keeping the rail inside the message area discussed in #15461.

For context, the affected conversation had 496 incoming user-role messages when checked. That includes updates from other threads and automatic messages, so the mark count can grow much faster than the number of AI turns.

JJulius Marminge8d ago

Reproduced in the web dev app on main a12d6ed942, Linux Chromium at 1280×800. Seeded an isolated conversation with 600 synthetic user messages and loaded all earlier turns. The 2px marks are about 0.85px apart and merge into a continuous rectangle; the initial 75-message view has distinct marks. This is separate from the vertical overflow reported in #15461. macOS Electron has not been checked.

600-message minimap on current main