[Bug]: Expanding “Worked for …” higher up in a thread scrolls to the end #4568

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 long thread with an older completed turn whose progress is collapsed behind a Worked for … row.
2. Make sure there is enough conversation after that turn that the end of the thread is well below the viewport.
3. Scroll up to the older Worked for … row so you are no longer at the end of the thread.
4. Expand the row.

Expected behavior

The viewport should preserve the reader’s position. Ideally the clicked Worked for … row remains visually anchored while its hidden content expands.

Actual behavior

Expanding the older Worked for … row scrolls the viewport to the end of the thread, losing the reader’s place.

The amount of later content matters: if the thread is too short for the end to be offscreen, the jump is not observable.

Impact

Major degradation or frequent failure. On long threads, inspecting an earlier turn repeatedly throws the reader back to the newest content.

Version or commit

Observed in T3 Code desktop 0.0.28. A synthetic local fixture on 0e43e7fe0eef91c41fe19286148b781a532bebc3 did not reproduce the jump, so the exact trigger may be release-specific or depend on additional live thread state.

Environment

NixOS/Linux desktop app (Electron).

Logs or stack traces

No relevant error is emitted.

Screenshots, recordings, or supporting files

I attempted to capture this with an isolated long-thread fixture. The current source build preserved scrollTop in settled and active-turn variants, so I am not attaching a misleading non-reproduction recording.

Workaround

Avoid expanding older Worked for … rows in long threads, or manually scroll back to the prior position after the jump.