KeyboardProvider overrides system insets on Android potentially affecting native views

[leonardorib]

Describe the bug
When the KeyboardProvider is rendered and statusBarTranslucent is true, which is always the case for edge-to-edge, the top system inset is overriden, which can impact Android native views relying on it.

Code snippet
See the repo for reproducing

Repo for reproducing
https://github.com/leonardorib/keyboardcontroller-insets-issue-repro

I added a README in there with some context and a video.

To Reproduce
Steps to reproduce the behavior:

1. On Android, make sure you are on edge-to-edge (e.g install react-native-edge-to-edge) or has statusBarTranslucent always true.
2. Render a native android view that relies on the top system inset from the statusbar
3. Render the KeyboardProvider
4. The top inset is now 0

Expected behavior
Native views that rely on system insets should ideally still be able to rely on those values.

Smartphone (please complete the following information):

• Desktop OS: macOS 15.5
• Device: Samsung Galaxy M14 (physical device) and Pixel 8 emulator
• OS: 14 and 15
• RN version: 0.79.5
• RN architecture: new
• JS engine: Hermes
• Library version: 1.17.5

Additional context
I came across this issue when integrating with RevenueCat paywalls. The idea is: you create a Paywall in their dashboard, calls presentPaywallor renders the PurchasesUI.Paywall component and the paywall you built will be rendered in the app.

I noticed that the paywall close button was colliding with the statusbar on Android. It was not being able to account for the statusbar size. At first I thought it was an issue with their SDK, but after I removed the KeyboardProvider from react-native-keyboard-controller the issue was solved.

After some investigation I noticed that react-native-keyboard-controller replaces the system window insets on Android:

react-native-keyboard-controller/android/src/main/java/com/reactnativekeyboardcontroller/views/EdgeToEdgeReactViewGroup.kt

Lines 115 to 120 in f5d6ea2

	defaultInsets.replaceSystemWindowInsets(
	defaultInsets.systemWindowInsetLeft,
	if (this.isStatusBarTranslucent) 0 else defaultInsets.systemWindowInsetTop,
	defaultInsets.systemWindowInsetRight,
	defaultInsets.systemWindowInsetBottom,
	)

When I replaced if (this.isStatusBarTranslucent) 0 else defaultInsets.systemWindowInsetTop with simply defaultInsets.systemWindowInsetTop, therefore keeping it all as default, I didn't get the issue anymore.

How Revenuecat Paywall relies on it

I noticed they are relying on it for example here:

https://github.com/RevenueCat/purchases-android/blob/daa30fdb874145878e40ffea154351da4dcbc4ea/ui/revenuecatui/src/main/kotlin/com/revenuecat/purchases/ui/revenuecatui/composables/CloseButton.kt#L23-L29

https://github.com/RevenueCat/purchases-android/blob/daa30fdb874145878e40ffea154351da4dcbc4ea/ui/revenuecatui/src/main/kotlin/com/revenuecat/purchases/ui/revenuecatui/composables/InsetSpacers.kt#L13-L19

Notes

I am not sure how much is that system insets replacement really needed for the library purposes, which is why I didn't open a PR removing it.

Screenshots

From my repo with the reproducer:

keyboard-controller-insets-issue-demo.webm

[kirillzyusko]

Hey @leonardorib

Thank you for opening such a detailed issue ❤️

When I replaced if (this.isStatusBarTranslucent) 0 else defaultInsets.systemWindowInsetTop with simply defaultInsets.systemWindowInsetTop, therefore keeping it all as default, I didn't get the issue anymore.

I thinks I added this code intentionally. Below is the difference how it works with/without this code:

0 inset	default systemWindowInsetTop
telegram-cloud-document-2-5440655251046692538.mp4	telegram-cloud-document-2-5440655251046692537.mp4

Basically header jumps a lot when I supply non-zero padding and if StatusBar is translucent 🤷‍♂️ I didn't investigate why exactly, maybe the problem is somewhere in react-native-screens/react-native-safe-area-context libs, because react-navigation uses this libs for rendering header (and according to video header changes its size).

Native views that rely on system insets should ideally still be able to rely on those values.

Theoretically yes, but I know that react-native-safe-area-context library uses a more sophisticated approach and basically it detects root view and its location on the screen and based on its location it calculates its insets (and with this approach safe-area-context properly detects insets even with my code I think):

The other interesting observation is that if I put defaultInsets.systemWindowInsetTop code, then react-native-safe-area-context will report 24/0 when I click disable/enable. For me it looks like native views are changing its position when I disable/enable edge-to-edge and we see one jump, then react-native-safe-area-context propagates event to JS, it re-calculates its paddings and we see another update, when header get a correct position again 🤷‍♂️

I know I didn't provide a solution, but I hope I gave a little bit more info on why that code has been added 😅 Maybe it's possible to provide other options for presentPaywall, like:

const paywallResult: PAYWALL_RESULT = await RevenueCatUI.presentPaywall({
    insets: { top: 24, bottom: 0 }, // devs can specify their own paddings if needed
});

[leonardorib]

@kirillzyusko

I know I didn't provide a solution, but I hope I gave a little bit more info on why that code has been added 😅 Maybe it's possible to provide other options for presentPaywall, like:

const paywallResult: PAYWALL_RESULT = await RevenueCatUI.presentPaywall({
insets: { top: 24, bottom: 0 }, // devs can specify their own paddings if needed
});

Just as a note in case other people using Revcat see this: I didn't face the issue with presentPaywall in particular because it shows the paywall as an independent modal where the statusbar is not translucent (not sure if it was intentional on their side), therefore the inset won't make a difference.

The issue is really when you need to render the <Paywall> component on a screen of your own, which is our case, and you want the translucent effect.

But yeah of course I see your point, the same idea of allowing custom insets could apply to the paywall component.

At the moment for our use case the workarounds are either hiding the statusbar in the paywall or wrapping with safe area and sacrificing the translucent effect at the top but ensuring the close button is reachable.

Theoretically yes, but I know that react-native-safe-area-context library uses a more sophisticated approach and basically it detects root view and its location on the screen and based on its location it calculates its insets (and with this approach safe-area-context properly detects insets even with my code I think):

Haha yeah I wondered the exact same thing: "but how react-native-safe-area-context does it?" and went look in their code what was the strategy there.

I think this is why it is not a so common problem at the moment since probably most people using react-native are relying on react-native-safe-area-context to access the safe area insets. It was only when I needed something that was relying on the Android more intuitive/common approach that this became an issue. I'm only guessing it is common for native Android to do like Revcat does, but I am not an expert Android developer 😅.

I thinks I added this code intentionally. Below is the difference how it works with/without this code:
Basically header jumps a lot when I supply non-zero padding and if StatusBar is translucent 🤷‍♂️ I didn't investigate why exactly, maybe the problem is somewhere in react-native-screens/react-native-safe-area-context libs, because react-navigation uses this libs for rendering header (and according to video header changes its size).

Oh interesting! Thank you so much for clarifying this ❤️

I'll maybe try looking into it when I have some free time. I can't promise much but I can try 😁

[kirillzyusko]

The issue is really when you need to render the component on a screen of your own, which is our case, and you want the translucent effect.

But yeah of course I see your point, the same idea of allowing custom insets could apply to the paywall component.

Can you render it within additional View and specify style={{paddingTop: top}} where top you get from useSafeAreaInsets?

At the moment for our use case the workarounds are either hiding the statusbar in the paywall or wrapping with safe area and sacrificing the translucent effect at the top but ensuring the close button is reachable.

If you embed that in view and that view will have a padding then you'll not loose translucency effect? Or I'm missing something?

[sbassin]

This also affects Expo SDK 55, where edgeToEdgeEnabled=true is now set by default in gradle.properties during prebuild. This means DeviceInfo.isEdgeToEdge returns true, react-native-is-edge-to-edge's isEdgeToEdge() returns true, and KeyboardProvider forces statusBarTranslucent=true — zeroing out systemBars.top for all downstream native views.

In our case, react-native-screens 4.23.0's CustomToolbar.onApplyWindowInsets receives top=0 and applies no header padding, causing all Stack headers to render behind the status bar.

We're using the same workaround identified above — patching replaceStatusBarInsets in View.kt to always pass through the real sysBars.top:

val adjustedTop = sysBars.top

The content margin set in setupWindowInsets() correctly handles the layout offset (0 when translucent). The dispatched insets should preserve the real value so downstream views can apply their own padding independently.

Environment: react-native-keyboard-controller 1.20.7, react-native-screens 4.23.0, React Native 0.83.2, Expo SDK 55

[kirillzyusko]

@sbassin is it the same issue as described in #1292?

[kirillzyusko]

@sbassin a potential fix for your problem could be a flow like "detect if edgeToEdgeEnabled=true" and if yes, then pass original insets? Inside replaceStatusBarInsets. I added detection in https://github.com/kirillzyusko/react-native-keyboard-controller/pull/1185/changes

If I understand correctly, when this lib enforced edge-to-edge it had to intercept insets to make other libs working as expected. Now, when behavior is defined at RN core we need to pass insets through?

I'm also not sure if it's caused by my lib or not, because before everything was working. But as noticed in #1292 the issue started to happen only after new RNS version usage. So maybe it's a bug in RNS (I already fixed some issues there related to edge-to-edge). I'm not saying that bug is definitely there, but libs may conflict, yes.

I need to double and triple check everything - why it started to happen, what is causing this etc. before making any changes, because it's very easy to keep insets unchanged, but it may break lib for other RN/RNS versions 🤔