[Bug] Windows Hub chat auto-scrolls back to an old position after each assistant reply #1285

Activity

1. github-project-automation

   added this to Windows Companion Appon Sep 2, 2026
2. github-project-automation

   moved this to Backlog in Windows Companion Appon Sep 2, 2026
3. clawsweeper

   added

   P2Normal priority bug or improvement with limited blast radius.Normal priority bug or improvement with limited blast radius.

   impact:ux-frictionUser-facing flow adds avoidable confusion or support burden without fully blocking progress.User-facing flow adds avoidable confusion or support burden without fully blocking progress.

   on Sep 2, 2026
4. clawsweeper commented on Sep 2, 2026

   

   clawsweeperBot

   on Sep 2, 2026 – with ClawSweeper

   More actions

   Thanks for the context here. I did a careful shell check against current main, and this is already implemented.

   Close as implemented: the native chat timeline already preserves a reader’s position unless it is following the tail, and the fix shipped in the reported v2026.7.1-2 release.

   So I’m closing this as already implemented rather than keeping a duplicate issue open.

   Review details

   Best possible solution:

   Keep the released anchoring behavior and reopen only with a current-release trace showing a session update changes the viewport despite this path.

   Do we have a high-confidence way to reproduce the issue?

   No. Read-only inspection found that an ordinary sessions update publishes metadata without a history reload, while tail navigation only runs for a changed tail when the reader is already following it.

   Is this the best way to solve the issue?

   Yes. The existing keyed tail-follow policy is the narrow maintainable solution because it preserves an earlier reading position while retaining bottom follow for new messages.

   Security review:

   Security review: No pull-request patch is under security review.

   AGENTS.md: found and applied where relevant.

   What I checked:

   • Session refresh does not reload the chat timeline: The sessions-updated handler applies the new session metadata and publishes a snapshot. It does not force a history reload or remount the native chat surface. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:1081, b8dc6091d0d4)
   • Scroll policy preserves a non-following reader: The timeline queues navigation only when the displayed tail changes and the reader is already near the bottom; scroll changes update that following state. This prevents a normal session-list snapshot from moving someone reading earlier messages. (src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:131, b8dc6091d0d4)
   • Stable request identity prevents refresh-triggered tail jumps: A tail-position request is keyed by session, timeline generation, history revision, and an explicit scroll token, rather than every published snapshot. (src/OpenClaw.Tray.WinUI/Chat/ReactorChatTimeline.cs:103, b8dc6091d0d4)
   • Fix provenance: Commit ca8fb4a introduced the current bottom-anchoring implementation as “fix(chat): stabilize bottom anchoring (fix(chat): stabilize bottom anchoring #1089)”. (src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:220, ca8fb4a404ad)
   • Release provenance: Tag v2026.7.1-2 points at f46400a and that release commit contains ca8fb4a, so the bottom-anchoring fix is included in the reporter’s named release. (f46400aab24e)

   Likely related people:

   • karkarl: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
   • calebeden: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

   Codex review notes: model internal, reasoning high; reviewed against b8dc6091d0d4; fix evidence: release v2026.7.1-2, commit ca8fb4a404ad.
5. clawsweeper

   closed this as completedon Sep 2, 2026
6. Gubruce commented on Sep 2, 2026

   

   Gubruce

   on Sep 2, 2026

   Author

   More actions

   Hi @clawsweeper, thanks for the check — but I can still reproduce this on the shipped v2026.7.1-2, and I found the specific trigger.

   Key trigger: the scroll anchor gets "pinned" to an old position when a reply is long AND its content loads asynchronously (e.g. a Markdown table rendering, or images loading in after the text), causing the message height to change non-continuously (in jumps) after the assistant finishes replying.

   Steps to reproduce:

   1. Ask a question that produces a long reply containing a table and/or images.
   2. Wait for the reply to finish; while the images/table are still rendering (async load), the message height grows in steps.
   3. The chat view auto-scrolls back to an earlier position and stays pinned there ("stuck"), instead of following the latest message.

   The "preserve reader position unless following the tail" logic doesn't cover the case where height changes discontinuously — the scroll anchor isn't recomputed after the async content finishes loading.

   Happy to attach a screen recording if useful. Could you please re-check with this trigger / reopen?

   👀React with 👀1Reacted by clawsweeper
7. github-actions

   locked as resolved and limited conversation to collaborators on Sep 4, 2026
8. samanthamsong

   removed this from Windows Companion Appon Sep 4, 2026