[Android] Tab content stays blank after navigating away and back over a PagerView (regression 8.0.5 → 9.0.2)

[GaelCO]

Environment

• react-native-pager-view: 9.0.2 (last working version: 8.0.5)
• @react-navigation/material-top-tabs: 7.6.15 (react-native-tab-view 4.3.2)
• react-native: 0.86.2
• react: 19.2.3
• Platform: Android
• New architecture: enabled

Description

A screen using createMaterialTopTabNavigator (even with a single tab, so a single-page PagerView) goes blank after the user navigates to another screen pushed on top via a Stack.Navigator, then navigates back. The tab bar and navigation state are still correct, but the page content is empty — no swipe/resize recovers it.

Bisected on our end: reverting only react-native-pager-view from 9.0.2 to 8.0.5 (no other change) fixes it, so this is a regression introduced in 9.0.0. That release replaced the Android implementation from ViewPager2/RecyclerView with a Jetpack Compose HorizontalPager (ComposePagerView, #1092). Suspicion: the Compose-hosted page doesn't get a fresh re-composition/re-layout when the surrounding Fragment/Activity view is covered by another screen and then revealed again.

Reproducible Demo

1. Screen A is a createMaterialTopTabNavigator with a single tab rendering some content (a PagerView under the hood, even with just 1 page).
2. From that tab's content, navigate forward to a screen pushed on a Stack.Navigator on top of it.
3. Navigate back (pop the stack screen) to Screen A.
4. The tab's content area is blank — the PagerView page no longer renders anything, even though the tab bar/navigation state is correct. No user interaction (swipe/resize) recovers it.

[troZee]

Hi @GaelCO 👋
Thanks for reporting this. Could you please add a minimal reproducible example directly in example/src/MaterialTopTabExample.tsx and open a small PR or share a branch with it?

That will let us run the exact setup locally and investigate the interaction with Material Top Tabs properly.

[GaelCO]

Hi,

I add a sample on this branch : https://github.com/GaelCO/react-native-pager-view/tree/repro/issue-1103-material-top-tab-blank-content

[GaelCO]

I asked Claude (Anthropic's coding assistant) to dig into this, and here's its assessment:

The regression traces back to how react-native-screens handles a covered screen. When a screen is pushed on top of a screen using PagerView (directly or via createMaterialTopTabNavigator), react-native-screens doesn't just hide the covered screen's native Fragment — it fully removes it and later re-adds the same Fragment instance when the covering screen is popped. That remove/re-add cycle destroys and recreates the Fragment's view-tree Lifecycle.

ComposePagerView's ComposeView ties its Compose composition to that lifecycle context. After the Fragment is torn down and rebuilt, the composition never recomposes again — not even its LaunchedEffect coroutines resume — so the pager area stays permanently blank even though it's reattached to the window correctly. This reproduces with a single line change from 8.0.5 (before the Fabric/Compose rewrite in 9.0.0), which never had this problem since it didn't route rendering through a Compose composition tied to the Android view lifecycle.

Why this fix

The fix recreates the ComposeView itself from scratch on every attach, instead of trying to keep the same instance (or its composition) alive across the detach/reattach cycle. A freshly created ComposeView, added while the parent is already attached to a window, behaves identically to the very first mount — which always renders correctly. The composition is disposed explicitly (onDropViewInstance) rather than relying on DisposeOnDetachedFromWindow, since that strategy would otherwise dispose (and never recreate) it on every such cycle.

While testing, we also caught a related bug this exposed: the pager was seeding its position from initialPage (only ever set once, at first mount) instead of currentPage (kept in sync as the user swipes). Recreating the composition on every reattach would otherwise snap the pager back to page 0 after any swipe + cover/reveal cycle. Fixed by seeding from currentPage instead.

What's not fully understood

I want to be upfront that this fix works around the symptom rather than fully explaining the underlying Compose behavior. Before landing on it, three other approaches were tried and failed in ways that suggest something deeper in how Compose's Recomposer/coroutine dispatcher interacts with a transient window detach:

1. Keeping the same ComposeView permanently attached and never disposing its composition — the pager stayed blank forever after one detach/reattach cycle.
2. The same, but with an explicit invalidate() call after reattach — no change.
3. The same, but backed by an independent Recomposer we create and run ourselves, never tied to the Fragment's lifecycle at all — the pager was still blank, and a diagnostic LaunchedEffect ticking every second via plain delay() froze permanently on detach and never resumed, even 20+ seconds after reattaching, with a Recomposer we never cancelled.

That last result is hard to explain: it suggests something below the Recomposer level (possibly AndroidUiDispatcher's reliance on Choreographer, or some other window-attach-sensitive scheduling in Compose-UI) stops processing coroutines for a composition after its hosting view detaches from a window — independent of which Recomposer is driving it. Recreating the ComposeView sidesteps this entirely rather than explaining it.

If a maintainer with more Compose-internals context has an idea of what's actually going on there, I'd genuinely like to know — it might point to a more targeted fix, or to something worth reporting upstream to Compose itself.

You can find the proposal fix on this branch : https://github.com/GaelCO/react-native-pager-view/tree/repro/issue-1103-material-top-tab-blank-content%2Bfix.

I asked him to dig deeper into the more general problem he suspects.

[GaelCO]

I hit this same symptom while investigating a related issue in react-native-pager-view (#1103 — a PagerView using ComposeView internally goes blank after the screen hosting it is covered and revealed again). I asked Claude (Anthropic's coding assistant) to dig into the root cause, and it traced it down to a specific, reproducible race in Compose-UI itself. Sharing the findings here since it matches this issue exactly and points to the precise mechanism.

Root cause

ScreenFragment.onCreateView() reuses the same screen View (via screen.recycle()) but returns a brand new wrapper FrameLayout each time the Fragment's view is destroyed and recreated. This means the Fragment's per-view Lifecycle (viewLifecycleOwner) is a new object on every cover/reveal cycle — the old one is destroyed (ON_DESTROY), a new one is created fresh.

If a ComposeView further down that tree is reused across this cycle (rather than being recreated too), it breaks because of how androidx.compose.ui.platform.WrappedComposition (internal to Compose-UI, in Wrapper.android.kt) handles this:

• The first time ever it's notified that ViewTreeOwners are available for its AndroidComposeView, it registers itself as a Lifecycle observer (lifecycle.addObserver(this)) and waits reactively for ON_CREATE to actually call Composition.setContent().
• On every subsequent notification (e.g. after the Fragment view — and thus the ViewTreeLifecycleOwner — has changed), it does not re-register as an observer. It just synchronously checks lifecycle.currentState.isAtLeast(CREATED) at that exact instant, and silently skips calling setContent() if that's not yet true — with nothing left to retry it later.

That's a real, narrow timing race, confirmed empirically. Logging the ViewTreeLifecycleOwner identity and its state transitions across a cover/reveal cycle gives:

event=ON_PAUSE lco=181126200 -> STARTED
event=ON_STOP lco=181126200 -> CREATED
event=ON_DESTROY lco=181126200 -> DESTROYED // old Fragment view-lifecycle destroyed

onAttachedToWindow lco=122515091 state=INITIALIZED // new Fragment view-lifecycle, but not CREATED yet
event=ON_CREATE lco=122515091 -> CREATED // ...arrives ~7ms later — too late
event=ON_START lco=122515091 -> STARTED
event=ON_RESUME lco=122515091 -> RESUMED

At the exact synchronous moment the reused ComposeView's setContent() runs again during onAttachedToWindow(), the new Lifecycle is still INITIALIZED. Compose's synchronous state check fails, content is silently dropped, and since there's no observer on the new Lifecycle, nothing ever retries — the composition is permanently stuck, even though the new Lifecycle reaches RESUMED a few milliseconds later.

(Traced by decompiling compose-ui:1.7.8's AndroidComposeView, WrappedComposition, and Wrapper_androidKt — worth double-checking whether this asymmetry still exists in newer Compose-UI releases.)

Workaround that worked for us

In react-native-pager-view, rather than trying to keep the same ComposeView (or its composition) alive across the cycle, we fully discard and recreate the ComposeView object itself on every onAttachedToWindow(). A brand-new ComposeView always gets a brand-new WrappedComposition, which takes the "first time ever" branch (reactive addObserver, robust to the timing race) — indistinguishable from a first mount, which always works.

For apps that can't/don't want to do that at the component level, detachPreviousScreen={false} on the covered screen (native-stack) should avoid triggering this Fragment recreation in the first place, at the cost of keeping the previous screen's native view around.

[GaelCO]

Would you like me to submit a PR with the fix?
If so, would you prefer I keep the example related to the bug or remove it?

[GaelCO]

Upon seeing issue #1104, I realized the proposed fix wasn't the right one, as it wouldn't address issue 1104. I propose a solution that handles both.

[GaelCO]

Update: the fix that was merged for this issue (recreating the whole ComposeView from scratch every time the Fragment is covered and revealed) does stop the pager from going blank, but it has a side effect. Since it also discards and rebuilds every page's native view host on each cover/reveal cycle, any state that lived in that native view, like a FlatList's scroll position, gets reset too. That's what's being reported in #1104.

Both issues share the same root cause. react-native-screens fully removes and re-adds a covered screen's Fragment instead of just hiding it, which destroys that Fragment's view-tree Lifecycle. The previous fix worked around that by rebuilding everything from scratch on every cycle.

I pushed an updated fix on fix/1103-1104 (https://github.com/GaelCO/react-native-pager-view/tree/fix/1103-1104) that addresses the root cause instead of working around it. The ComposeView now gets its own self-managed Lifecycle, via setViewTreeLifecycleOwner and ViewCompositionStrategy.DisposeOnLifecycleDestroyed, instead of relying on the ambient Fragment one. That Lifecycle only reaches DESTROYED when the view is actually dropped by React Native, not merely covered, so the composition and every page's native view now survive the cover/reveal cycle untouched. No more blank pager for this issue, and no more state loss for #1104.

Kept the existing repro and regression test for this issue and added one for #1104 as well. Both pass with this change, verified manually on a physical Android device too.

[troZee]

https://github.com/callstack/react-native-pager-view/releases/tag/v9.0.3