From 2a56e08eb9af9f8544d5542de23830a5dda141de Mon Sep 17 00:00:00 2001 From: npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67d <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@sprout-oss.stage.blox.sqprod.co> Date: Thu, 18 Jun 2026 12:56:40 -0400 Subject: [PATCH] fix(desktop): restore overflow-anchor:none on live scroll containers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit useAnchoredScroll is meant to be the single owner of scrollTop, but both live scroll containers had lost the [overflow-anchor:none] class (it survived only on the thread loading skeleton, which never scrolls). With it gone, Chromium's native scroll-anchoring heuristic re-engaged and applied its own scrollTop correction on prepend — picking its own anchor element — while the hook applied a second scrollBy correction on top. When the two anchors diverged the corrections stacked, producing the residual jiggle that survived the single-owner rewrite. Restoring the class on both live containers (MessageTimeline timeline + MessageThreadPanel body) hands scroll ownership back to the hook alone. This is a real-wheel-only symptom: native scroll anchoring barely fires under synthetic scrollTop= writes, so the headless suite stayed green while a manual macOS scroll pass surfaced it. scroll-history e2e 6/6, tsc clean. Co-authored-by: Tyler Longwell Signed-off-by: Tyler Longwell --- desktop/src/features/messages/ui/MessageThreadPanel.tsx | 2 +- desktop/src/features/messages/ui/MessageTimeline.tsx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/desktop/src/features/messages/ui/MessageThreadPanel.tsx b/desktop/src/features/messages/ui/MessageThreadPanel.tsx index 06b12a274..cb3bc0b5a 100644 --- a/desktop/src/features/messages/ui/MessageThreadPanel.tsx +++ b/desktop/src/features/messages/ui/MessageThreadPanel.tsx @@ -383,7 +383,7 @@ export function MessageThreadPanel({ const threadScrollRegion = (