You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I searched existing issues and discussions and did not find a duplicate.
I checked the current scroll behavior in web, desktop, Android, and iOS code.
I am describing a concrete reading problem.
Area
apps/web, apps/desktop, and apps/mobile
Problem or use case
When an LLM produces a long answer, T3 Code follows the live edge and leaves the viewport at the bottom of the answer. I then have to scroll back to the beginning before I can read it in its natural top-to-bottom order.
The useful starting position for a completed answer is its first line, not its last line. This is especially noticeable on a phone, where only a small part of a long response fits on screen.
I checked the current implementation before filing this request:
Android and iOS share the React Native thread feed. Its follow latch starts enabled and maintainScrollAtEnd follows data and item-layout changes.
Web calls scrollToEnd for normal sends and keeps live follow enabled. The first turn in a new thread has partial send-time anchoring, but streaming adjustments still move the viewport to reveal the growing end.
Desktop wraps the web chat, so it inherits the web behavior.
Proposed solution
Add a reader-first response anchor across all clients:
When the first visible assistant answer text for a turn appears, place the beginning of that answer near the top of the usable viewport, below any fixed header.
Keep that reading position stable while the rest of the answer streams. Do not chase the growing tail by default.
If the answer fits in the viewport, avoid unnecessary movement or blank space.
Keep the existing Jump to latest control. Reaching the bottom or pressing that control may re-enable live-tail following.
Never override deliberate user navigation. If the user has already scrolled elsewhere, preserve that position.
Apply the same behavior to web, desktop, Android, and iOS.
Tool activity may continue to use the current live-follow behavior before answer text exists. The important transition is when the readable assistant answer begins.
Why this matters
LLM answers are written top to bottom. Starting at the bottom forces every long response into the same repeated interaction: receive answer, scroll upward, find the first line, then begin reading. A response anchor removes that work and makes completion notifications useful because opening the thread lands at the place where reading should start.
Smallest useful scope
For long answers, anchor the first assistant text block when it appears and stop automatic tail-follow until the user explicitly returns to the bottom.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Before submitting
Area
apps/web,apps/desktop, andapps/mobileProblem or use case
When an LLM produces a long answer, T3 Code follows the live edge and leaves the viewport at the bottom of the answer. I then have to scroll back to the beginning before I can read it in its natural top-to-bottom order.
The useful starting position for a completed answer is its first line, not its last line. This is especially noticeable on a phone, where only a small part of a long response fits on screen.
I checked the current implementation before filing this request:
maintainScrollAtEndfollows data and item-layout changes.scrollToEndfor normal sends and keeps live follow enabled. The first turn in a new thread has partial send-time anchoring, but streaming adjustments still move the viewport to reveal the growing end.Proposed solution
Add a reader-first response anchor across all clients:
Tool activity may continue to use the current live-follow behavior before answer text exists. The important transition is when the readable assistant answer begins.
Why this matters
LLM answers are written top to bottom. Starting at the bottom forces every long response into the same repeated interaction: receive answer, scroll upward, find the first line, then begin reading. A response anchor removes that work and makes completion notifications useful because opening the thread lands at the place where reading should start.
Smallest useful scope
For long answers, anchor the first assistant text block when it appears and stop automatic tail-follow until the user explicitly returns to the bottom.
Related work
Acceptance criteria
Contribution
All reactions