Repository navigation
[Bug]: iPad: a background thread finishing resets the visible thread's scroll position #15162
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/mobile
Steps to reproduce
- On iPad, use the split layout with the thread sidebar visible.
- Open thread A containing a response longer than the viewport.
- Switch to thread B and send a message.
- Return to A before B finishes. A opens near the end of its response.
- Without scrolling or interacting, wait for B to finish.
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.
Activity
nekohasekai commentedon Oct 3, 2026
Superseded by #15165, submitted using the repository’s Bug report template with its automatic labels.
nekohasekai commentedon Oct 3, 2026
Reopened as requested in #15165. That report was recreated solely to submit through the repository’s Bug report template and apply its automatic bug and needs-triage labels. Please apply those labels here; this remains the canonical report.
juliusmarminge commentedon Oct 3, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks @nekohasekai 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.nekohasekai commentedon Oct 3, 2026
@juliusmarminge Confirmed: #14808 fixes the scroll reset reported here.
I tested commit
6d8c61ab4b011d5256f3886c496266b27b1a062bwith a fresh native build (react-native-keyboard-controller1.22.6) on an iPad Pro 11-inch (M5) Simulator running iPadOS 26.5, in landscape split view.Both reproduction cases passed: the first message in an empty B, and a follow-up in the same B. After switching back to the long thread A, A stayed selected and kept its scroll position through B’s Working → Done transition. A’s visible content was pixel-identical before and after in both runs. Both cases reproduced the reset on the original build (
31a9da1).Verification video — 8 seconds, MP4
The clip shows the follow-up case at normal speed, using synthetic threads only.
juliusmarminge commentedon Oct 3, 2026
Note
Grok responding on behalf of Julius.
Closing as fixed by #14808 (
react-native-keyboard-controller1.22.4 → 1.22.6). @nekohasekai confirmed the iPad split-layout repro on that PR: after a fresh native build, thread A kept its scroll position through B's Working → Done in both the first-message and follow-up cases.