Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#3,311 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
73/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
react, typescript
Área
frontend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
845
Forks
297
Merge medio
1 d 3 h
PR fusionados (30 d)
24

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de GetStream/stream-chat-react

Todos los issues de GetStream/stream-chat-react

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.