fix(Android, Stack): Constraint FormSheet height by top inset #3404

t0maboro · 2025-11-18T12:30:09Z

Description

Add a new prop to control formSheet overflow behavior relative to the status bar.

This PR introduces a new prop that allows to control whether a formSheet should overflow the status bar and display cutouts or not. The purpose of this addition is to align the formSheet behavior more closely with iOS, where the top safe area inset is respected by default.

Caution

This is a breaking change that has an impact on the sheet's size (and indirectly may lead to significant visual changes). To bring back the original behavior, you can set sheetShouldOverflowTopInset prop to true

Fixes https://github.com/software-mansion/react-native-screens-labs/issues/565

Changes

Added a class for coordinating the bottom sheet slide animation, to be started after we receive insets.
Added a class to aggregate listeners for insets on bottom sheet level
Added sheetShouldOverflowTopInset prop

Screenshots / GIFs

Here you can add screenshots / GIFs documenting your change.

You can add before / after section if you're changing some behavior.

With overflow

with-overflow.mov

Without overflow

without-overfow.mov

Test code and steps to reproduce

Test with 3336 with API levels over and below 30

Checklist

Included code example that can be used to test this change
Ensured that CI passes

apps/src/tests/Test3336.tsx

kligarski · 2025-11-19T11:35:21Z

src/types.tsx

+   *
+   * @platform android
+   */
+  sheetShouldOverflowStatusBar?: boolean;


I think that we should highlight in the description that with sheetShouldOverflowStatusBar: false, ratios from sheetAllowedDetents will be relative to safe area, not the container height (e.g. if you set sheetAllowedDetents: [0.5], the height (relative to window) will be different depending on sheetShouldOverflowStatusBar prop).

Another question is whether this is the behavior we want.

Another question is whether this is the behavior we want.

Imo it does make sense to calculate detent within the available sheet space. Like, having detent 1.0 and sheetShouldOverflowStatusBar: false would result in content cutoff if we'd calculate maxHeight as detent*containerHeight

Yep. + this way I believe we keep alignment between platforms, which is nice when possible

guides/GUIDE_FOR_LIBRARY_AUTHORS.md

kkafar

Looks good overall. I have few comments / requests.

Looking at the final comment from the review: https://github.com/software-mansion/react-native-screens/pull/3404/files#r2545394786 (read first please)

I think that we should treat this as a fix & make the sheets respect insets by default.

Therefore we should work on naming. First, it can not be overflowStatusBar, since it is too specific and not entirely true, right? Doesn't this PR also handle display cutout? Can you verify this? How does it look when there is a big display cutout present (you can turn it on in emulator settings (google for it please))?

If so, we should rather refer to it as topInset IMO.

Additionally if the default's gonna be false, then we should phrase it more like sheetShouldIgnoreTopInset. Then false as the deafult value & if someone wants to active the prop he sets it to true.

What do you think?

android/src/main/java/com/swmansion/rnscreens/bottomsheet/BottomSheetTransitionCoordinator.kt

...oid/src/main/java/com/swmansion/rnscreens/bottomsheet/BottomSheetWindowInsetListenerChain.kt

kkafar · 2025-11-20T10:18:29Z

src/types.tsx

+   *
+   * @platform android
+   */
+  sheetShouldOverflowStatusBar?: boolean;


Yep. + this way I believe we keep alignment between platforms, which is nice when possible

kkafar · 2025-11-20T10:39:08Z

guides/GUIDE_FOR_LIBRARY_AUTHORS.md

+
+When set to `false`, the sheet's layout will be constrained by the status bar insets from the top and the detent ratios will then be measured relative to the adjusted height (excluding the top inset). This means that sheetAllowedDetents will result in different sheet heights depending on this prop.
+
+Defaults to `true`.


I'm in two minds regarding the default value here.

There are a couple of things to consider here:

what's the previous behaviour, so that we don't introduce breaking changes,

alignment between platforms,

reasonable default.

I think that the previous state is that the sheet does expand to full screen height, so that it does not respect the top insets.

As per alignment - iOS does the opposite, it respects the insets (cutout, status bar, etc.).

As per reasonable default - I think it is to respect the insets.

IMO we could treat this as a fix/improvement rather than behaviour change and make it aligned with iOS.

I think that the previous state is that the sheet does expand to full screen height, so that it does not respect the top insets.

Correct

As per alignment - iOS does the opposite, it respects the insets (cutout, status bar, etc.).

Correct

As per reasonable default - I think it is to respect the insets.

50/50 😄

The only argument I have is to keep the compatibility, because that change will have some impact on the appearance in existing apps, which are having 1.0 detent. Not a strong preference, aligning with iOS seems to be a reasonable approach either.

I'm proposing this 5cc9372

t0maboro · 2025-11-20T15:57:05Z

Looks good overall. I have few comments / requests.

Looking at the final comment from the review: https://github.com/software-mansion/react-native-screens/pull/3404/files#r2545394786 (read first please)

I think that we should treat this as a fix & make the sheets respect insets by default.

Therefore we should work on naming. First, it can not be overflowStatusBar, since it is too specific and not entirely true, right? Doesn't this PR also handle display cutout? Can you verify this? How does it look when there is a big display cutout present (you can turn it on in emulator settings (google for it please))?

If so, we should rather refer to it as topInset IMO.

Additionally if the default's gonna be false, then we should phrase it more like sheetShouldIgnoreTopInset. Then false as the deafult value & if someone wants to active the prop he sets it to true.

What do you think?

I wasn't sure about the support for display cutout, but added it here: 25a543b . Then here: 5cc9372 I'm proposing the new name for the prop.

kkafar

I have two more remarks. I'll come back to this PR tomorrow with few more questions.

android/src/main/java/com/swmansion/rnscreens/bottomsheet/SheetDelegate.kt

t0maboro changed the title ~~feat(Android, Stack): Allow FormSheet to be constrained by insets~~ feat(Android, Stack): Allow FormSheet to be constrained by StatusBar Nov 19, 2025

t0maboro marked this pull request as ready for review November 19, 2025 09:59

t0maboro requested review from kkafar, kligarski and kmichalikk November 19, 2025 09:59

t0maboro force-pushed the @t0maboro/form-sheet-flex-end branch from a10f3a4 to ccfc096 Compare November 19, 2025 11:17

kligarski reviewed Nov 19, 2025

View reviewed changes

Base automatically changed from @t0maboro/form-sheet-flex-end to main November 19, 2025 11:43

t0maboro force-pushed the @t0maboro/form-sheet-below-status-bar branch from 328f05a to 0646967 Compare November 19, 2025 11:45

t0maboro requested a review from kligarski November 19, 2025 11:56

kligarski reviewed Nov 19, 2025

View reviewed changes

guides/GUIDE_FOR_LIBRARY_AUTHORS.md Outdated Show resolved Hide resolved

t0maboro requested a review from kligarski November 19, 2025 13:42

kligarski approved these changes Nov 19, 2025

View reviewed changes

kkafar reviewed Nov 20, 2025

View reviewed changes

t0maboro requested a review from kkafar November 20, 2025 15:57

t0maboro changed the title ~~feat(Android, Stack): Allow FormSheet to be constrained by StatusBar~~ fix(Android, Stack): Constraint FormSheet height by top inset Nov 20, 2025

kkafar reviewed Nov 20, 2025

View reviewed changes

android/src/main/java/com/swmansion/rnscreens/bottomsheet/SheetDelegate.kt Outdated Show resolved Hide resolved

android/src/main/java/com/swmansion/rnscreens/bottomsheet/SheetDelegate.kt Outdated Show resolved Hide resolved

t0maboro requested a review from kkafar November 21, 2025 08:50

t0maboro added 11 commits November 21, 2025 12:27

Working, but why?

72d7ad6

Make function internal

350ffc6

Make internal

af5d90e

Add some comments

8ada358

Remove attributes

ca5a0f1

Add comments

05fa419

Add comment

cbc32b7

Split logic between architectures

1db288e

Make private

b9db77e

Add prop

226fcaf

Fix after rebase

d0c3006

t0maboro added 29 commits November 21, 2025 12:27

Add comment

669e8dd

Separate logic for resolving container height

6fe336b

Remove paper annotation

ad7e975

Set proper default

e30d8c6

Add docs

f863611

Update test

e506b80

Support for API levels <30

2cbbf01

Add todo

9ad3841

Aggregate listeners

5788373

Rename

96ad493

Drop bottom inset support from prop

6807084

Fix keyboard flickering

125f19d

Remove todo

a20c1b7

Cleanup

6cd5c35

Fix after rebase

b2fee50

Update docs

31e7613

Linter

2df618b

Correct docs

a46236f

Deduplicate insets

1301027

Move some logic to ScreenStackFragment

caa6100

Remove extra args

cad91e8

Remove rolling insets

f72dcb4

Formatting

ca1b308

Add display cutout

81a227a

Rename

e6cfffa

Fix default value

2ee4fb9

Take max

3ca99f5

Rename

bcc5240

Fixes after rebase

1cbdabc

t0maboro force-pushed the @t0maboro/form-sheet-below-status-bar branch from 30baf69 to 1cbdabc Compare November 21, 2025 11:35


		When set to `false`, the sheet's layout will be constrained by the status bar insets from the top and the detent ratios will then be measured relative to the adjusted height (excluding the top inset). This means that sheetAllowedDetents will result in different sheet heights depending on this prop.

		Defaults to `true`.

Uh oh!

fix(Android, Stack): Constraint FormSheet height by top inset #3404

Are you sure you want to change the base?

fix(Android, Stack): Constraint FormSheet height by top inset #3404

Conversation

t0maboro commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Changes

Screenshots / GIFs

With overflow

Without overflow

Test code and steps to reproduce

Checklist

Uh oh!

Uh oh!

kligarski Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

t0maboro Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

t0maboro Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kkafar Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kkafar left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kkafar Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

kkafar Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

t0maboro Nov 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

t0maboro Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

t0maboro commented Nov 20, 2025

Uh oh!

kkafar left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

t0maboro commented Nov 18, 2025 •

edited

Loading

t0maboro Nov 19, 2025 •

edited

Loading

t0maboro Nov 20, 2025 •

edited

Loading