Scroll position changes when navigating back to a list in react navigation stack

[moh3n9595]

Current behavior

Upon navigating backwards, the list's scroll position is different from where it was originally.

Expected behavior

The scroll position should not change.

Platform:

• Web
• iOS
• Android

Environment

2.0.1

[ericpoulinnz]

@naqvitalha sorry for the tag but this is a longstanding issue (#635 ) which V2 has not fixed. It makes for a terrible UX for a very common use case involving lists.

[SergioAN007]

Just set navigator option: screenOptions={{detachPreviousScreen: false}}

[spyshower]

Same issue here, but it happens when pushing a new screen.

[vatsal-bk]

Any updates on this? I am facing same issue

[mayconmesquita]

Thanks! This solved the issue for me. More details in the docs.

Just set navigator option: screenOptions={{detachPreviousScreen: false}}

[takumatakuma]

We hit this in a production Expo app (expo-router Stack → @react-navigation/native-stack on web) and traced it to a specific missing guard. Sharing the measurements and a patch in case it helps.

It is FlashList-specific, not a browser or navigator behaviour

Four scrollers rendered inside the same subtree, toggled display: none → flex once (Chromium via Playwright, @shopify/flash-list@2.0.2, react-native-web@0.21.2):

scroller	before hide	after show
plain DOM overflow:auto div	2000	2000
react-native-web ScrollView	2000	2000
react-native-web FlatList	2000	2000
@shopify/flash-list	2000	0

The browser restores scrollTop across a display:none round trip by itself. The position is lost only because the list shrinks its own content to nothing while hidden.

Mechanism

1. NativeStackView.js:94 keeps the unfocused screen mounted with display: none.
2. ResizeObserver fires; react-native-web's useElementLayout re-measures the hidden node and dispatches onLayout({width: 0, height: 0}).
3. RecyclerView's first useLayoutEffect has no zero-size guard, so updateLayoutParams runs with a 0 window; every row then measures clientHeight === 0 in the item-layout effect.
4. The resulting total (0) is written as the content container's inline height (ViewHolderCollection), so the scroller genuinely has nothing to scroll and the offset is clamped to 0.

getAbsoluteLastScrollOffset() is still correct while hidden, but collapses to 0 once the list is shown again, so an app-side "save and restore" workaround cannot use it as a source of truth either.

Second, less visible symptom

While hidden, every row mounts and stays mounted after the screen comes back — with 600 items I measured 63 rendered rows → 600 while hidden → still 600 after returning. Virtualization is effectively disabled for the rest of the session after one navigation round trip.

Patch that fixes both

Skipping the layout work when the list measures 0×0 (a hidden list has nothing to lay out; the next real measurement restores it):

// dist/recyclerview/RecyclerView.js — effect 1, right after measureParentSize()
if (outerViewLayout.width === 0 && outerViewLayout.height === 0) {
  return;
}

// effect 2 (item layout), before measuring the rows
if (internalViewRef.current) {
  const parentSize = measureParentSize(internalViewRef.current);
  if (parentSize.width === 0 && parentSize.height === 0) {
    return;
  }
}

Measured with the same harness:

	unpatched	patched
scroll position after returning	0	2000
mounted rows while hidden	63 → 600	63 → 63
mounted rows after returning	600	63

Still reproducible on 2.3.2 — the guard is absent there too. Happy to open a PR against src/recyclerview/RecyclerView.tsx if maintainers agree with the approach (in particular whether the early return should also skip when only one dimension is 0, which I deliberately did not do to avoid affecting legitimately zero-width/height lists).