feat: prevent dialogs from being covered by keyboard

[sandeepsengupta]

This will probably need some tweaking before release (as described below), but I wanted to share what I have found so far.

Dialogs containing TextInput objects do not currently move up when the keyboard is opened, which can result in the keyboard obscuring part of the dialog. This commit fixes this by changing the overlay view (the <View> with overlayStyle) to a KeyboardAvoidingView with behavior="height".

As discussed here, using android:windowSoftInputMode="adjustResize" is no longer sufficient on Android, now that Android is enforcing edge-to-edge mode.

This fixes #5 and fixes #35.

Important note: It may be best to make these changes optional by placing them behind a boolean avoidKeyboard prop. See the "Alternative to Avoid Issues and Breaking Changes" section at the end of this comment.

This solution is partially inspired by callstack/react-native-paper#5023.

Screen Recordings

Current behavior on Android 17 (API 37.0):

Note: This behavior occurs even though android:windowSoftInputMode="adjustResize" is set in AndroidManifest.xml.

Screen.Recording.2026-07-30.at.10.13.47.AM.mov

Behavior on Android 17 (API 37.0) with patch applied:

Screen.Recording.2026-07-30.at.10.19.29.AM.mov

Current behavior on iOS 26.5:

Screen.Recording.2026-07-30.at.10.27.19.AM.mov

Behavior on iOS 26.5 with patch applied:

Screen.Recording.2026-07-30.at.10.29.48.AM.mov

Known Issues

This change unfortunately seems to cause some minor side effects, as described below.

Side effect 1: Slightly different behavior when dialog content exceeds available space

The following screenshots are of Android 7, where edge-to-edge is not enforced. Here, the dialog contains too much content and no ScrollView, so it cannot be expected to render in a reasonable way. The only relevant thing to notice here is that the screenshots on the right are slightly different from those on the left:

Android 7 without patch (left) and with patch (right):

Android 7 without patch (left) and with patch (right):

Side effect 2: Dialog positioned slightly below center

This happens on older versions of Android where edge-to-edge is not enforced (i.e., where this patch is not necessary). Applying this fix sometimes causes the dialog to appear slightly below center, as shown below. This may not happen the first time the keyboard is opened, but it does happen when the keyboard is opened for the second time.

Android 14 without patch (left) and with patch (right):

Android 14 without patch (left) and with patch (right):

Side effect 3: Dialogs with ScrollViews can be too tall

When edge-to-edge is not enabled (that is, on older versions of Android), dialogs containing ScrollViews are often slightly too tall when the keyboard is visible:

Android 14 without patch (left) and with patch (right):

Side effect 4: Occasional visual glitch

With the patch applied, in rare cases, dismissing the keyboard results in the following strange visual glitch. This only happens occasionally; it works fine most of the time.

Alternative to Avoid Issues and Breaking Changes

This may constitute a breaking change, since some users of this library may already be implementing their own workarounds to reposition the dialog when the keyboard is visible.

To prevent it from being a breaking change, and to give users the option to avoid the side effects described in "Known Issues" above, I wonder if we can add a boolean avoidKeyboard prop to enable or disable these changes. What do you think?

Thanks for this useful library!

[douglasjunior]

Nice job, thank you! Three things to consider:

1. Have you tested navigating between behavior modes?
2. The avoidKeyboard=true/false option works well; be sure to document it.
3. It would be beneficial to add an option to change the behavior as well, along with its documentation.

[sandeepsengupta]

Thanks for the comments! As for behavior, I have found that height works best. Here are some screenshots I took just now on an Android 17 emulator:

From left to right: height, padding, position

From left to right: height, padding, position

I suspect we may not want to expose behavior="position" to the user, given how badly it works here. With behavior="padding", the dialog seems to be slightly lower than expected, so behavior="height" seems to work best.

(Note: In the screenshots with behavior="height", you might have noticed that the amount of padding below the Close button got reduced when I opened the keyboard. However, this is just because the dialog contains a lot of content with no ScrollView. Reducing the amount of text in the dialog, or adding a ScrollView, prevents this issue.)

Based on the above info, do you think it is still worth adding a behavior option?

[douglasjunior]

Nice, let's expose only the avoidKeyboard property. Regarding the note about the dialog containing excessive content without a ScrollView, that's not an issue. It's the library user's responsibility to either reduce the text or wrap it in a ScrollView.

[sandeepsengupta]

Sounds good! And yes, I agree that the behavior with excessive dialog content is not an issue here.