Repository navigation
[Bug]: Expanding a tool call or thinking row near the composer leaves its content hidden behind the composer #21967
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 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).
- 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
Activity
juliusmarminge commentedon Oct 19, 2026
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 doespinDisclosureToEndscroll to the bottom (lines 696-700). OtherwiseshouldRestoreVisibleContentPositionkeeps 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.
juliusmarminge commentedon Oct 21, 2026
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.