[Bug]: BottomSheet mounts invisible on Android — containerHeight stuck at sentinel (Reanimated 4 reaction misses raw->container sync)

[christian-apollo]

Version

v5

Reanimated Version

v3

Gesture Handler Version

v2

Platforms

Android

What happened?

On Android, a non-modal BottomSheet with an initial index >= 0 intermittently mounts invisible — the component and its children are in the tree, but the sheet is positioned entirely off screen (at window height / closed) and never animates in. It happens most often on a cold app start when the screen mounts while the JS thread is busy, so the container onLayout lands a second or two after mount. Under that contention it reproduces ~every time; in lighter conditions it's intermittent.

Root cause

useAnimatedLayout keeps the measured container height in two fields of the layout state: rawContainerHeight (written directly by BottomSheetHostingContainer's onLayout) and containerHeight (the effective value everything else reads). containerHeight is derived from rawContainerHeight by a useAnimatedReaction:

useAnimatedReaction(
  () => state.value.rawContainerHeight,
  (result, previous) => {
    if (result === previous) return;
    if (result === INITIAL_LAYOUT_VALUE) return;
    state.modify(_state => {
      'worklet';
      _state.containerHeight = modal ? result - verticalInset : result;
      return _state;
    });
  },
  [state, verticalInset, modal]
);

On Reanimated 4 this reaction's handler can miss the initial INITIAL_LAYOUT_VALUE (-999) → measured-height transition (it does not fire for the first layoutState.modify). When that happens, containerHeight stays at the sentinel even though rawContainerHeight is correct.

Consequences cascade from there:

• useAnimatedDetents early-exits (if (containerHeight === INITIAL_LAYOUT_VALUE) return {}), so detents is undefined.
• isLayoutCalculated never becomes true (it requires normalized detents).
• The mount positioning reaction never runs animateToPosition / setToPosition, so animatedPosition stays at its initial Dimensions.get('window').height — i.e. fully off screen.

Notably, useDerivedValue consumers of the same layout state do recompute on the modify; only the useAnimatedReaction handler is skipped. That points at a Reanimated-4 reaction-vs-modify timing issue rather than app code.

Note: I'm actually on react-native-reanimated 4.4.0; the version dropdown above tops out at v3, so I selected the closest non-deprecated option.

Reproduction steps

• Render a non-modal <BottomSheet index={0}> (with a couple of snapPoints) on a screen that mounts during a cold app start while the JS thread is busy.
• Observe that the sheet mounts off screen and never animates in.
• Add logging to isLayoutCalculated and confirm containerHeight === -999 while rawContainerHeight already holds the measured height.

Reproduction sample

https://snack.expo.dev/@gorhom/bottom-sheet---issue-reproduction-template

Relevant log output

[BottomSheetHostingContainer::handleLayoutEvent] height:832
[isLayoutCalc] containerH=-999 rawContainerH=832 handleH=0 detents=none -> false

[lxr-mwhite]

I'm seeing a similar issue in my app where the BottomSheet is mounted initially, but then disappears. I can see it in the react native dev tools component tree but it's off screen. I've also actually seen it a few times on iOS but it is definitely more intermittent than Android.

On Android I can reproduce it pretty easily if the bottom sheet mounts around the same time that my app requests the user's location permission. As soon as the permission modal is dismissed, the bottom sheet disappears. For testing purposes I added a 3 second delay to the location permission request, in which case interacting with the modal does not make the BottomSheet disappear.

@christian-apollo I tried your fix for my specific case but it unfortunately didn't solve the issue. However it does appear to fix a different issue where the bottom sheet could still animate on mount even if animateOnMount={false}.

In my case I have 3 snapPoints with the following props:

index={1}
enableDynamicSizing={false}
animateOnMount={false}

"@gorhom/bottom-sheet": "5.2.14"
"react-native-reanimated": "4.3.1"

[christian-apollo]

@lxr-mwhite It seems to be different, in my case it was initially not mounted/visible.

[peterlazar1993]

@christian-apollo I am also hitting this issue with reanimated 4.4.0 but not 4.3.1.

Were you able to patch the library? Or do you think this is an issue with reanimated itself?

[bulkinav]

Hi,

Below is the solution from AI:

@gorhom+bottom-sheet+5.2.14.patch

---

The issue happens with Reanimated 4.4.0 when the initial container layout update is missed by the useAnimatedReaction that syncs rawContainerHeight into containerHeight.

Before this patch:

• BottomSheetHostingContainer writes only rawContainerHeight during onLayout.
  useAnimatedLayout later copies rawContainerHeight into containerHeight via useAnimatedReaction.
• On Reanimated 4.4.0, that reaction can miss the first INITIAL_LAYOUT_VALUE -> measured height transition.
• containerHeight remains stuck at the sentinel value.
• Detents are not calculated.
• isLayoutCalculated stays false.
• The sheet never moves from the closed/off-screen position.

After this patch:

• BottomSheetHostingContainer updates rawContainerHeight and containerHeight in the same layoutState.modify call.
• This removes the dependency on the initial useAnimatedReaction firing correctly.
• The existing reaction can still handle later changes, but the initial measured layout is now applied synchronously with the raw layout update.
• The modal/non-modal height behavior is preserved by passing the internal $modal flag into BottomSheetHostingContainer.

Why this is needed:

Reanimated 4.4.0 introduced changes around update scheduling and synchronous props handling. In some cold-start or busy-JS-thread cases, bottom-sheet can receive the measured container height, but the derived effective height remains unset. This patch keeps those two layout fields consistent at the source of the measurement.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue was closed because it has been stalled for 5 days with no activity.