Repository navigation
[Bug]: iPad: a background thread finishing resets the visible thread's scroll position #15165
Description
Activity
Note
Grok responding on behalf of Julius.
Triage
Thanks @nekohasekai for refiling this from #15162 with the template, and for the careful repro, the no-send control, and the diagnostic run. That last part (offset going to 0 with unchanged list identity and content size) was a big help. This looks like a real iOS scroll reset rather than a remount or LegendList adjusting for new rows.
What's likely happening
ThreadFeedscrolls throughKeyboardAwareLegendList, which usesKeyboardChatScrollView. Onmainat31a9da1that's stillreact-native-keyboard-controller@1.22.4withreact-native-reanimated@4.7.0. In 1.22.4,ScrollViewWithBottomPaddingleavescontentOffsetout of the firstuseAnimatedPropsevaluation, so Reanimated 4.7 treats a later keyboard-driven offset like a style. The next React commit of that list drops the prop, and Fabric resets the native offset to{0, 0}. That's the bug fixed upstream in kirillzyusko/react-native-keyboard-controller#1629 (merged).Sending a message on B opens the keyboard and arms this; your no-send control doesn't, which matches what you recorded. A jump to exactly 0 is that reset, not a scroll-to-end.
One piece isn't pinned down yet: something still commits A's list around B's Working → Done transition. A's shell and details stay stable when only the other thread changes, and no feed path deliberately scrolls the open thread when another run settles, so the exact subscription hasn't been isolated.
Likely fix area
The open PR #14808 bumps the controller to 1.22.6, which includes
contentOffsetin the initial animated props. It's still going through review and would need a new native build. Checking this repro on that branch (A should keep its offset when B finishes) would show whether it covers this trigger too. A maintainer will decide on the fix direction.
Before submitting
Area
apps/mobile
Steps to reproduce
Expected behavior
A keeps its scroll position while another thread responds in the background.
Actual behavior
A jumps to the beginning around the time B changes from Working to Done. A remains selected.
Reproduced twice: once with B's first message and once with a follow-up in the same B. Switching between A and B without sending a message did not reset A during a 47-second control.
Impact
Major degradation or frequent failure
Version or commit
main @ 31a9da1
Environment
T3 Code Dev; iPad Pro 11-inch (M5) Simulator; iPadOS 26.5; landscape split layout; local backend; Codex provider using gpt-6-astra.
Logs or stack traces
A separate diagnostic run showed A's native scroll offset changing to 0 while its list identity and content dimensions remained unchanged. The exact cause is not yet confirmed.
Screenshots, recordings, or supporting files
Watch the 9-second reproduction (MP4)
Normal speed, with no cuts between switching to A and the reset. Recorded on an unmodified checkout using synthetic threads.
Workaround