Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

bug: MessageList restoreAnchor oscillates on iOS WebKit after loading older messages, leaving the list at an arbitrary scroll position

Geschlossen
  • Stimmt etwas nicht?
#3,311 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
73/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
react, typescript
Bereich
frontend

Rechercherichtung

Start in the TypeScript source for useScrollLocationLogic (src/components/MessageList/hooks/), at restoreAnchor/applyAnchor, plus the preserve-anchor entry point in useMessageListScrollManager. Replace the per-frame relative scrollBy correction with an absolute listElement.scrollTop derived from the anchor's offset within scroll content, so re-applying it cannot compound. Look for existing tests of these scroll hooks, add coverage showing repeated application converges instead of oscillating, and check whether the 1200 ms settle timeout and sign-flip guard still behave as described.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Describe the bug

On iOS (Safari, and Chrome iOS, which also runs on WebKit), the non-virtualised MessageList moves the user away from the message they were reading every time an older page of messages loads. They usually end up near the newest messages. Our users describe it as "can't scroll up through the conversation, it keeps jumping back".

The cause is the older-page anchor restore in useScrollLocationLogic. On iOS WebKit its per-frame relative scrollBy correction never settles. It flips the list between two scroll positions until the 1200 ms settle timeout stops it, and the list stays wherever it is at that moment.

To Reproduce

  1. On an iOS device or simulator, open a channel with more than 25 messages, so there is more than one page.
  2. Scroll up with touch until older messages start loading. At that point the list's scrollTop is between 1 and 250, so useMessageListScrollManager takes the preserve-anchor path.
  3. When the older page is prepended, the view jumps away from the message you were reading, often by more than a screen height towards the bottom.
  4. Scroll up again. The next page load jumps again.

We logged the calls by patching Element.prototype.scrollBy, scrollTo and the scrollTop setter on .str-chat__message-list, with stack traces. This is one older-page load on the iOS 26.3 simulator:

t(ms)  caller                          arg              scrollTop before call
8904   restoreAnchor.applyAnchor       scrollBy +1983   222
8948   restoreAnchor.queueNextFrame    scrollBy -1360   3565
8958   restoreAnchor.queueNextFrame    scrollBy +1360   845
9041   restoreAnchor.queueNextFrame    scrollBy -780    3565
9052   restoreAnchor.queueNextFrame    scrollBy +780    2005
9072   restoreAnchor.queueNextFrame    scrollBy -780    3565
...    (~70 calls, alternating -780 / +780, scrollTop flipping 2005 <-> 3565)
10088  restoreAnchor.queueNextFrame    scrollBy +780    2005
       -> 1200 ms timeout; list left at scrollTop 3565 (scrollHeight 4526, clientHeight 381)
  • The user was at scrollTop ≈ 218 before the load.
  • Every later older-page load repeats the pattern. We saw bursts of 60–68 calls with deltas of ±1452, ±254, and mixed values up to about 4900.
  • Each scrollBy moves the list by about twice the requested delta, so the next frame measures the same error with the opposite sign.

That fits the geometry read in the frame after a scrollBy still reflecting the pre-scroll position on iOS. With a relative correction, the loop flips between two positions instead of settling.

Where (14.12.1, dist/es/components/MessageList/hooks/MessageList/):

  • useScrollLocationLogic.mjs, restoreAnchor (≈ lines 65–121). applyAnchor computes offsetDelta from getBoundingClientRect and calls listElement.scrollBy({ top: offsetDelta }) (≈ line 82) on every animation frame. It stops after 2 stable frames, or at setTimeout(cleanup, 1200).
  • useMessageListScrollManager.mjs: it is entered from restoreAnchor(preservedAnchor) (≈ line 84) in preserve-anchor mode.

Expected behavior

After older messages are prepended, the message the user was reading stays where it was.

Suggested fix

Make the restore idempotent:

  1. Compute the anchor's position without depending on the current scroll. For example, use the anchor element's offsetTop relative to the list's scroll content instead of getBoundingClientRect.
  2. Assign an absolute listElement.scrollTop = anchorContentTop - anchor.offsetTop instead of a relative scrollBy.

Re-applying that on later frames can't compound, whatever the engine's read-after-write timing. A cheaper guard is to stop the loop as soon as offsetDelta changes sign, but that only limits the damage.

What we tried as integrators:

  • No public prop turns off the anchor path; disableScrollManagement is internal.
  • overflow-anchor: none on the list has no effect.
  • Keeping pagination in stick-to-top mode avoids the loop, but drops the reading position by a whole page.

Screenshots

n/a. The scroll log above shows the behaviour; we can share the full logs and the logging snippet.

Package version

  • stream-chat-react: 14.12.1. The scroll hooks are byte-identical from 14.9.0 to 14.12.2, so latest is affected.
  • stream-chat-css: bundled with stream-chat-react 14.12.1
  • stream-chat-js: 9.53.0

Desktop (please complete the following information):

Not affected:

  • Chrome (Playwright Chromium): native scroll anchoring keeps the anchor in place, so restoreAnchor makes zero corrections.
  • Desktop WebKit 26.6 (Playwright): one scrollBy, then it settles.

Smartphone (please complete the following information):

  • Device: iPhone 17 Pro simulator (logged above); iPhone 15 Pro simulator (visual repro); a physical iPhone (field report)
  • OS: iOS 26.3 and iOS 17.5 (simulators); the physical iPhone's OS version is unknown
  • Browser: Safari (simulators); Chrome iOS 154 (field report)

Additional context

The list is the non-virtualised <MessageList /> with default props, inside Channel / Window, with messages paginated 25 at a time.

Vorherrschende Sprache
TypeScript
Sterne
845
Forks
298
Ø Merge
18 Std. 42 Min.
Gemergte PRs (30 T.)
23

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus GetStream/stream-chat-react

Alle Issues in GetStream/stream-chat-react

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.