Sign up
View stargazersSign up

[Bug]: Expanding a tool call or thinking row near the composer leaves its content hidden behind the composer#21967

opened8d agobyLln-bodicherla

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

  1. Open a thread where a tool call or thinking/reasoning row sits near the bottom of the timeline, just above the composer. A running turn makes this easy, but it also happens with completed rows as long as the timeline is not pinned to the very end (for example, the "Working…" row or a later message follows it, or you are scrolled slightly above the end).
  2. Click the row to expand it.

Expected behavior

The expanded content is scrolled into view above the composer. The row header stays visible, so a row taller than the viewport can still be read from the top.

Actual behavior

The row header stays where it is and the expanded content grows downward behind the composer. To read it, you have to scroll the thread up manually until the content clears the text box.

From reading the code: a work-row disclosure calls suspendEndScrollMaintenanceForDisclosure. When the timeline is at the end, pinDisclosureToEnd re-pins it and the content shows. Otherwise maintainVisibleContentPosition only restores the toggled row (shouldRestoreVisibleContentPosition), so the row stays fixed and its new height ends up under composerOverlayHeight. No step checks whether the expanded content is still visible above the composer.

Impact

Minor bug or occasional failure

Version or commit

main at a71a6c37

Environment

apps/web (desktop and web). Reproduced in a Chromium browser test of MessagesTimeline with a 200px composer overlay: after expanding a tool call placed just above the composer, its content ended about 247px below the visible edge above the composer.

Logs or stack traces

No response

Screenshots, recordings, or supporting files

No response

JJulius Marminge8d ago

Note

Grok responding on behalf of Julius.

Thanks for the code trace, it matches current main. A disclosure toggle records whether the timeline is at the end (apps/web/src/components/chat/MessagesTimeline.tsx:728-734). Only in that case does pinDisclosureToEnd scroll to the bottom (lines 696-700). Otherwise shouldRestoreVisibleContentPosition keeps just the toggled row in place (lines 736-740), and nothing then checks whether the new content clears the composer overlay.

Keeping the clicked row header where it was is deliberate, so the thing you clicked doesn't jump away. The part that's off is the composer overlay. Content that grows behind it looks like the end of the thread even though there's more to read, which is different from content simply running past the bottom of a normal scroll area. Scrolling just enough to reveal the expanded content, without pushing the header out of view, would keep both behaviors.

This is separate from #19880, which is about stacked composer notices covering the last messages, not about expanding a row.

Accepting this as a minor bug.

JJulius Marminge6d ago

Reproduced on current main (70e5e384da) in Chromium on Linux at 1280×800 using the real web dev server and isolated stopped-thread data. With a later assistant response and the timeline above its end, expanding a command row at y=608 kept its header fixed while the work content extended to y=1047, behind the composer beginning around y=637. The open-issue duplicate scan found no matching report.