Android edge-to-edge: sheet content sits under system navigation bar / home indicator

[lemon-squared]

Summary

On Android with edge-to-edge enabled (RN edgeToEdgeEnabled=true, transparent navigation bar), ModalBottomSheet / BottomSheet content is laid out flush to the physical bottom of the window. Primary actions (Cancel / Done) sit under the gesture nav / 3-button bar.

The host already accounts for the top system inset (statusBars + displayCutout → contentRegionInset / Yoga padding). There is no equivalent for navigationBars() (or iOS home-indicator) at the bottom.

JS workarounds (paddingBottom / marginBottom on footers from useSafeAreaInsets()) are unreliable under the library’s Yoga + native translation model. What works for apps today is a flex sibling spacer with a hardcoded floor (e.g. 64dp) — a brittle consumer-side hack.

Environment

• @swmansion/react-native-bottom-sheet: ^0.16.2
• React Native: 0.86 (New Architecture / Fabric)
• edgeToEdgeEnabled=true in gradle.properties
• Transparent navigationBarColor / translucent system bars
• Reproduced on physical Android (gesture and 3-button nav)

iOS home indicator has the same class of problem for footers pinned to the sheet bottom.

Reproduction

import { useState } from "react";
import { Button, Text, View } from "react-native";
import { useSafeAreaInsets } from "react-native-safe-area-context";
import { ModalBottomSheet } from "@swmansion/react-native-bottom-sheet";

export function Example() {
  const [index, setIndex] = useState(0);
  const insets = useSafeAreaInsets();

  return (
    <>
      <Button title="Open" onPress={() => setIndex(1)} />
      <ModalBottomSheet
        detents={[0, "content"]}
        index={index}
        onIndexChange={setIndex}
        scrimColor="rgba(0,0,0,0.35)"
        surface={<View style={{ flex: 1, backgroundColor: "white" }} />}
      >
        <View style={{ padding: 16, gap: 12 }}>
          <Text>Actions at the bottom of the sheet</Text>
          {/* Even with insets.bottom, Cancel often still sits under the nav bar */}
          <View style={{ paddingBottom: insets.bottom }}>
            <Button title="Cancel" onPress={() => setIndex(0)} />
          </View>
        </View>
      </ModalBottomSheet>
    </>
  );
}

Expected: Cancel clears the system navigation / home indicator; sheet surface may still extend edge-to-edge underneath.

Actual: Cancel is obscured by the system nav. Footer padding/margin is often ineffective; apps need a consumer-side flex sibling gap + platform floor.

Why (from reading the native host)

In BottomSheetHostView.recomputeNativeGeometry() only the top inset is read:

val topInset =
  ViewCompat.getRootWindowInsets(this)
    ?.getInsets(WindowInsetsCompat.Type.statusBars() or WindowInsetsCompat.Type.displayCutout())
    ?.top ?: 0

That drives contentRegionInset / detent cap. The sheet container still anchors to the physical bottom of an edge-to-edge window. Absolutely positioned surface fills that region (correct for chrome), but in-flow content has no native bottom inset for navigationBars().

The README example of paddingBottom: insets.bottom assumes Yoga padding on children is enough; under Fabric + this host’s translation / content-offset path, that is not consistently true for footers.

Proposed API (either)

A) Automatic (preferred for edge-to-edge defaults)

When the window is edge-to-edge, apply navigationBars() (and iOS safe-area bottom) as a content-bottom inset, analogous to today’s top contentRegionInset:

• Surface still edge-to-edge (full sheet chrome under the nav bar).
• In-flow content / scrollables lay out above the nav bar.

B) Explicit prop

<ModalBottomSheet bottomInset={insets.bottom} ...>

or edges={['bottom']} / safeAreaBottom — applied natively in the content region (not only documented as a JS padding tip).

Related: #62 (native footer slot) and any detached-sheet bottomInset discussion — a shared native bottom inset would help both.

Sketch: Android inset change

Illustrative only — naming/state plumbing should match existing contentRegionInset / pushGeometryState patterns.

// BottomSheetHostView.recomputeNativeGeometry()

val rootInsets = ViewCompat.getRootWindowInsets(this)

val topInset =
  rootInsets
    ?.getInsets(WindowInsetsCompat.Type.statusBars() or WindowInsetsCompat.Type.displayCutout())
    ?.top ?: 0

val bottomInset =
  rootInsets
    ?.getInsets(WindowInsetsCompat.Type.navigationBars())
    ?.bottom ?: 0

val location = IntArray(2)
getLocationInWindow(location)

val topOverlap = (topInset - location[1]).coerceAtLeast(0)
val rootViewHeight = (rootView?.height ?: height)
val bottomOverlap =
  (location[1] + height - (rootViewHeight - bottomInset)).coerceAtLeast(0)

val cap =
  (if (extendUnderStatusBar) height else height - topOverlap)
    .toFloat()
    .coerceAtLeast(0f)

// Push both into state, e.g.:
// contentRegionInsetTop  → existing Yoga bottom-padding trick for top gap
// contentRegionInsetBottom → NEW: so in-flow content clears nav
pushGeometryState(
  width = width,
  height = height,
  insetTop = height - cap,
  insetBottom = bottomOverlap.toFloat(),
)

In the Fabric component descriptor / content wrapper, reserve insetBottom for in-flow children (Yoga padding or an extra content inset), while keeping surface on absoluteFill so the sheet chrome still draws under the system bar.

iOS: mirror with safeAreaInsets.bottom on BottomSheetHostingView when computing the content region.

Consumer workaround (today)

Until this lands, reserve a flex sibling under sheet children with a stable platform floor (avoid post-settle measureInWindow — it overshoots and causes layout jump):

<View style={{ flex: 1 }}>
  <View style={{ flex: 1, minHeight: 0 }}>{children}</View>
  <View style={{ height: Math.max(insets.bottom, Platform.OS === "android" ? 64 : 34) }} />
</View>

Footer paddingBottom: insets.bottom did not reliably clear the nav; a flex sibling spacer did.”

Happy to test a PR on RN 0.86 + edge-to-edge if useful.

[patrickmichalik]

Hello! The sheet intentionally does not apply safe-area insets to its content; consumers can use useSafeAreaInsets() where appropriate. The existing top-inset handling limits the maximum detent and is not equivalent to content padding. It can be disabled via extendUnderStatusBar.

I added the provided snippet to our edge-to-edge example app and tested it on a physical Pixel 10. paddingBottom: insets.bottom correctly keeps the Cancel button above the navigation area; the sheet’s native-translation path moves the already-laid-out subtree and does not bypass descendant Yoga padding.

If this fails on your end, please share a screenshot showing the result, ideally including the value of insets.bottom.

[lemon-squared]

Thanks for re-checking the minimal content-sheet case on a Pixel 10 — you were right about that path.

We re-tested and agree: on a short detents={[0, "content"]} sheet, paddingBottom: insets.bottom from useSafeAreaInsets() correctly keeps Cancel above the system navigation bar. Yoga padding is applied; the native-translation path does not bypass descendant padding in that layout. Our earlier claim that padding “never works” under the host was wrong for the README-style example.

What still fails (different layout)

Our product sheets are not that example. They use a tall fixed detent (~90% window), a flex: 1 column, a ScrollView, and a pinned footer (Cancel / Done). In that layout, the same paddingBottom: insets.bottom on the sheet root (or footer) still leaves Cancel under the system nav / 3-button bar.

We reproduced that on a physical Samsung SM-A035F (RN 0.86, New Arch, edgeToEdgeEnabled=true, 3-button nav):

• insets.bottom = 48
• initialWindowMetrics.bottom = 48
• Root uses only paddingBottom: insets.bottom (no sibling spacer, no platform floor)
• Cancel remains obscured by / flush against the system navigation controls

Screenshot attached (also shows the inset values painted on the sheet).

Minimal large-sheet repro

import { useState } from "react";
import {
  Button,
  Dimensions,
  ScrollView,
  Text,
  View,
} from "react-native";
import { useSafeAreaInsets } from "react-native-safe-area-context";
import { ModalBottomSheet } from "@swmansion/react-native-bottom-sheet";

export function LargeSheetInsetRepro() {
  const [index, setIndex] = useState(0);
  const insets = useSafeAreaInsets();
  const largeHeight = Math.round(Dimensions.get("window").height * 0.9);

  return (
    <ModalBottomSheet
      animateContentHeight={false}
      detents={[0, largeHeight]}
      index={index}
      onIndexChange={setIndex}
      scrimColor="rgba(0,0,0,0.35)"
      surface={<View style={{ flex: 1, backgroundColor: "white" }} />}
    >
      <View
        style={{
          flex: 1,
          minHeight: 0,
          padding: 16,
          paddingBottom: insets.bottom, // README pattern — insufficient here
          backgroundColor: "white",
        }}
      >
        <Text>
          insets.bottom = {insets.bottom}
        </Text>
        <ScrollView style={{ flex: 1, minHeight: 0 }}>
          {Array.from({ length: 12 }, (_, i) => (
            <Text key={i}>Scroll row {i + 1}</Text>
          ))}
        </ScrollView>
        <View style={{ borderTopWidth: 1, paddingTop: 12 }}>
          <Button title="Cancel" onPress={() => setIndex(0)} />
        </View>
      </View>
    </ModalBottomSheet>
  );
}

Expected: Cancel clears the system navigation bar (sheet chrome may still draw edge-to-edge).

Actual: With insets.bottom === 48, Cancel still sits under / against the nav.

Consumer workaround (today)

Until there is a native bottom content inset (or documented guidance for tall flex + pinned-footer sheets), we reserve a flex sibling under the children with a stable floor:

<View style={{ flex: 1, minHeight: 0 }}>
  <View style={{ flex: 1, minHeight: 0 }}>{children}</View>
  <View
    pointerEvents="none"
    style={{
      height: Math.max(
        insets.bottom,
        Platform.OS === "android" ? 64 : 34
      ),
    }}
  />
</View>

Footer paddingBottom: insets.bottom alone was not enough for this layout; the sibling + floor was.

Happy to iterate on API if you’d rather expose a native bottomInset / content-bottom inset analogous to today’s top contentRegionInset (detent-cap semantics aside). Closing the “simple padding is ignored” part of the original report; keeping this open for the large pinned-footer case if that’s useful.

[patrickmichalik]

Thanks! That clarifies what’s happening. The safe-area padding is being applied; the issue is the flex: 1 layout.

Sheet content is laid out inside a full-height stable container. Detent values determine the translation applied to that container, but they do not currently participate in the content’s Yoga layout. The flex: 1 root in this example uses the container’s full layout height. The footer is positioned at the bottom of that box, which is below the viewport when the container is translated to the requested detent. The safe-area padding is applied correctly, but relative to that off-screen bottom.

You can solve this by using height: largeHeight instead of flex: 1 on the root (at which point you can also leave detents at the default value, since 'content' will translate to largeHeight). We’ll look into constraining the in-flow content wrapper’s available Yoga height to the largest resolved detent while retaining the stable native container for positioning and animation.

[lemon-squared]

Thanks for the clear diagnosis and the quick back-and-forth — really appreciate the help.

Confirmed on our side (RN 0.86, edge-to-edge, Samsung SM-A225F + SM-A035F, insets.bottom = 48).

For tall pinned-footer sheets, height: largeHeight on the root (instead of flex: 1) + paddingBottom: insets.bottom clears Cancel above the system nav. We’re wrapping that in our product sheet helper going forward.

Leaving this open for the planned in-flow Yoga height constraint to the largest detent — that would remove the need for the explicit height workaround. Thanks again.