React-native-navigation: [V2] Android Keyboard issues

[Collin3]

Issue Description

Android keyboard will not dismiss on navigation when using a sideMenu layout. I tried using the blurOnUnmount option added from #4191, but it does not cover everything.

Steps to Reproduce

If you have a text input, followed by a FlatList or ScrollView with the keyboardShouldPersistTaps={'handled'}, when you tap a child of the FlatList or ScrollView, the onPress will kick off a navigation event that pushes onto the stack. During this navigation event, the keyboard will persist and will stay up on the new screen. This is only an issue on Android, and it is only a problem on android when you use a side menu layout. If I switch the layout to just be a stack, then the keyboard gets dismissed as expected on that navigation event.

Please let me know if you need more details. Thanks!

---

Environment

• React Native Navigation version: 2.2.0
• React Native version: 0.55.4
• Platform(s) (iOS, Android, or both?): Android only
• Device info (Simulator/Device? OS version? Debug/Release?): Simulator Pixel 2 API 28 using Android 8.1, as well as on an actual device of Samsung Galaxy S6 Android version 7.0

[Collin3]

Another related issue is that if you have the keyboard up and you swipe to open the left side menu, the keyboard will stay up.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If you believe the issue is still relevant, please test on the latest Detox and report back. Thank you for your contributions.

[lschuft]

Having the same issue after implementing sideMenu. Tried to execute Keyboard.dismiss() on componentWillUnmount but it doesn't work.

Also tried to the blurOnUnmount flag added in #4191 with setDefaultOptions, with no luck:

Navigation.setDefaultOptions({ blurOnUnmount: true });

@Collin3, did you have any luck with this?

[lschuft]

Okay, I managed to sorta fix it in my case. I did some native code debugging and the issue is that RNN is not honoring the default options set by setDefaultOptions(). Instead, it takes whatever is send as an options object when pushing the new screen in the stack. So the solution for me was just setting this value to true explicitely in each screen push to the stack, like so:

Navigation.push('main', {
      component: {
        name: 'ProtoApp.RegisterEvent',
        options: {
          topBar: {
            title: {
              text: 'title'
            }
          },
          blurOnUnmount: true
        }
      }
    });

While this does the trick, (and ignoring the fact that it takes a while to completely dismiss the keyboard) it's tedious to fix in apps with many screens. I haven't checked why does setDefaultOptions work for other options and not for this case, as I don't have time at the moment (and honestly this is my first time debugging native Android code).

If no one is able to, I'll try to check it later. I hope this info helps!

[Collin3]

@lschuft, I'm not 100% sure on this theory, but I think there's an issue in general with using setDefaultOptions and then also specifying things on navigation actions like push or in mergeOptions. This comment references an issue that I think could be the root problem here as well. Basically for nested objects, some of the deeper levels get ignored, reset, or overridden.

I also had to put blurOnUnmount on all of my screens, but even then I found some scenarios where the keyboard would stay up unexpectedly.

[masoudltf]

Another solution is:

import {Keyboard} from 'react-native';

componentDidAppear() {
        Keyboard.dismiss();
}

So you can create a 'BaseScreen' that all your screen extends from this.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If you believe the issue is still relevant, please test on the latest Detox and report back. Thank you for your contributions.

[Collin3]

This definitely has not been fixed, but there are some workarounds..

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If you believe the issue is still relevant, please test on the latest Detox and report back. Thank you for your contributions.

[stale[bot]]

The issue has been closed for inactivity.