What happened?

In a long session, after the user sends a new message while already at the latest/bottom position, the session timeline can jump back near the top of the rendered conversation instead of staying at the latest turn.

This was observed in the installed macOS app in the session titled Pawwork 性能测试 PR 查询与使用. The visible result is that the user sends a message and is suddenly taken away from the newest context. The exported diagnostics show the scroll viewport moving from bottom to near-top within one second, without a session switch, timeline remount, history load, or content-height change.

Which area seems affected?

App flow or product behavior

How much does this affect you?

Breaks an important workflow

Steps to reproduce

1. Open PawWork installed app on macOS.
2. Open a long session that is currently at the latest/bottom position.
3. Send a new user message.
4. Watch the session timeline immediately after submit.
5. In the affected case, the viewport jumps near the top/older part of the rendered timeline instead of staying at the latest turn.

Observed diagnostic evidence from the exported session log:

• 2026-05-07T11:59:37.427Z: session.action.submit for the final user message.
• 2026-05-07T11:59:37.447Z: still at bottom, scroll_top=12217.5, scroll_height=13122, client_height=905, distance_from_bottom=0, user_scrolled=false.
• 2026-05-07T11:59:38.383Z: jumped near top, scroll_top=6, scroll_height=13122, client_height=905, distance_from_bottom=12211, user_scrolled=true.
• 2026-05-07T11:59:38.384Z: incident.session_scroll_jump_to_top emitted.

Additional local diagnostic build evidence:

• A temporary instrumented packaged build reproduced the same class of behavior on the same session data.
• The added scroll-write diagnostics showed that before auto_scroll.scrollToBottomNow attempted to follow bottom, the scroll container was already at scrollTop=0.
• That suggests the first jump is not a direct auto_scroll write. It is likely a browser/render-window reset during the long-session DOM/window update, with auto-follow failing to reliably recover.

What did you expect to happen?

If the user is at the latest/bottom position when submitting a message, the timeline should remain pinned to the latest turn throughout submit, streaming, cancellation, and assistant response updates. It should not jump to older messages unless the user intentionally scrolls away.

PawWork version

2026.5.7

OS version

macOS 26.3.1

Can you reproduce it again?

Sometimes

Diagnostics

Exported session log used for evidence:

/Users/yuhan/Downloads/pawwork-session-log/pawwork-session-sunny-falcon-2026-05-07-11-59-46-scrollup.json

Likely files / code areas:

• packages/app/src/pages/session/message-timeline.tsx
• packages/app/src/pages/session/use-session-scroll-dock.ts
• packages/app/src/pages/session/use-session-history-window.ts
• packages/ui/src/hooks/create-auto-scroll.tsx

Initial fix boundary:

• Treat this as a bottom-follow invariance bug in the session timeline, not as a packaging issue.
• When the user was at bottom before submit/new message insertion, preserve or restore bottom through the rendered-window update.
• Do not rely only on userScrolled gesture state for this path, because the jump can be caused by a programmatic/browser layout reset rather than an intentional user scroll.

Suggested verification:

• Add deterministic E2E coverage for a long session where the viewport is at bottom, a user message is submitted, and the viewport remains near bottom.
• Include the cancellation/interrupted-response path if practical, since the local reproduction also showed the same instability class around stop/cancel.
• Run targeted session scroll unit tests and bun --cwd packages/app typecheck.