Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[0.71.0] [ANDROID 9] Keyboard events do not fire on Android 9 #35894

Closed
bigcupcoffee opened this issue Jan 19, 2023 · 5 comments
Closed

[0.71.0] [ANDROID 9] Keyboard events do not fire on Android 9 #35894

bigcupcoffee opened this issue Jan 19, 2023 · 5 comments

Comments

@bigcupcoffee
Copy link
Contributor

Description

Brief

After upgrading an app to 0.71 everything depending on keyboard events didn't work. After short investigation issue has been narrowed down to Android 9, as my real device is android 9, another real device that works perfectly is Android 12.

Issue is reproducible on AVD with Android 9 Pie.

Downgrading to 0.70.6 fixes this.

What exactly happens

Noticed that if subscribed to the events in App.js, the show event fires once as soon as app starts up. Could be related I guess?

Version

0.71.0

Output of npx react-native info

Is not necessary

Steps to reproduce

  1. Tap input
  2. Keyboard pops up, events do not

Snack, code example, screenshot, or link to a repository

I simply used fresh new app with these insertions:

  useEffect(() => {
    const didShow = Keyboard.addListener('keyboardDidShow', event => {
      console.log('keyboard did show');
    });
    const didHide = Keyboard.addListener('keyboardDidHide', event => {
      console.log('keyboard did hide');
    });

    return () => {
      didShow.remove();
      didHide.remove();
    };
  }, []);
  // add to the bottom of ScrollView
  <TextInput placeholder="input is here" />
@NickGerleman
Copy link
Contributor

RN 0.71 moved to the androidx WindowInsetsCompat for keyboard events on recent-ish versions of Android, which fixes some other longstanding issues 1e48274

The API is documented by Google to be reliable on Android 6+, but maybe that isn't the case...

Out of curiosity, what softInputMode is your activity? Could imagine that being a factor, but if WindowInsetsCompat isn't working as expected, the legacy code is still there, gated by an OS version check already.

@bigcupcoffee
Copy link
Contributor Author

bigcupcoffee commented Jan 19, 2023

Out of curiosity, what softInputMode is your activity? Could imagine that being a factor

@NickGerleman adjustResize of course (reproducible on template app).
Doesn't look very reliable if I could repro it on recommended Android 9 AVD image 🤷, can't blame my specific brand image here

@NickGerleman
Copy link
Contributor

Whelp... that's not good. If we aren't firing events at all, then isVisible(WindowInsetsCompat.Type.ime()) seems to not be returning correctly.

The documentation for that method is:

Returns whether a set of windows that may cause insets is currently visible on screen, regardless of whether it actually overlaps with this window. When running on devices with API Level 29 and before, the returned value is an approximation based on the information available. This is especially true for the IME type, which currently only works when running on devices with SDK level 23 and above.

If it isn't returning at all, on API 28, the last sentence doesn't seem accurate. The logic can be changed to avoid WindowInsetsCompat, and just use WindowInsets when natively present, falling back to RN's old heuristic for anything before.

@bigcupcoffee
Copy link
Contributor Author

bigcupcoffee commented Jan 19, 2023

Noticed that if subscribed to the events in App.js, the show event fires once as soon as app starts up. Could be related I guess?

It appears it does return something? Excuse if I'm being lost since I'm not friendly with native side, but apparently it just thinks that keyboard is permanently open 🤔

NickGerleman added a commit to NickGerleman/react-native that referenced this issue Jan 19, 2023
Summary:
Fixes facebook#35894

Android 11 added native support for querying whether the IME is present along with its size, as part of the WindowInsets API. D38500859 (facebook@1e48274) changed our logic for Android keyboard events to use it when available, fixing a longstanding issues where we could not reliably tell where the keyboard was open depending on softInputMode.

An androidx library WindowInsetsCompat aimed to backport some of the functionality to older versions of Android, with the same API, documenting IME queries to work down to API level 23 (Android 6). I used this, so that we would be able to remove our own logic for detecting keyboard insets once we supported 23+.

From an issue report, WindowInsetsCompat is not accurately returning whether the IME is open on at least Android 9. So this change makes it so we only use WindowInsets methods when they are provided by the OS (a tested golden path), and otherwise use the previously working heuristics on anything older.

Changelog:
[Android][Fixed] - Do not use WindowInsetsCompat for Keyboard Events

Differential Revision: D42604176

fbshipit-source-id: 123bd28f57898f186f2ca065b95f6995e67c0c1f
@fabOnReact
Copy link
Contributor

fabOnReact commented Jan 20, 2023

#14887 (comment)
Adding the link for documentation.

kelset pushed a commit that referenced this issue Jan 30, 2023
Summary:
Pull Request resolved: #35897

Fixes #35894

Android 11 added native support for querying whether the IME is present along with its size, as part of the WindowInsets API. D38500859 (1e48274) changed our logic for Android keyboard events to use it when available, fixing a longstanding issues where we could not reliably tell where the keyboard was open depending on softInputMode.

An androidx library WindowInsetsCompat aimed to backport some of the functionality to older versions of Android, with the same API, documenting IME queries to work down to API level 23 (Android 6). I used this, so that we would be able to remove our own logic for detecting keyboard insets once we supported 23+.

From an issue report, WindowInsetsCompat is not accurately returning whether the IME is open on at least Android 9. So this change makes it so we only use WindowInsets methods when they are provided by the OS (a tested golden path), and otherwise use the previously working heuristics on anything older.

Changelog:
[Android][Fixed] - Do not use WindowInsetsCompat for Keyboard Events

Reviewed By: christophpurrer

Differential Revision: D42604176

fbshipit-source-id: da6a0bbc34c36f8e6d4e4ac07bc96da048fd6aa8
OlimpiaZurek pushed a commit to OlimpiaZurek/react-native that referenced this issue May 22, 2023
Summary:
Pull Request resolved: facebook#35897

Fixes facebook#35894

Android 11 added native support for querying whether the IME is present along with its size, as part of the WindowInsets API. D38500859 (facebook@1e48274) changed our logic for Android keyboard events to use it when available, fixing a longstanding issues where we could not reliably tell where the keyboard was open depending on softInputMode.

An androidx library WindowInsetsCompat aimed to backport some of the functionality to older versions of Android, with the same API, documenting IME queries to work down to API level 23 (Android 6). I used this, so that we would be able to remove our own logic for detecting keyboard insets once we supported 23+.

From an issue report, WindowInsetsCompat is not accurately returning whether the IME is open on at least Android 9. So this change makes it so we only use WindowInsets methods when they are provided by the OS (a tested golden path), and otherwise use the previously working heuristics on anything older.

Changelog:
[Android][Fixed] - Do not use WindowInsetsCompat for Keyboard Events

Reviewed By: christophpurrer

Differential Revision: D42604176

fbshipit-source-id: da6a0bbc34c36f8e6d4e4ac07bc96da048fd6aa8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants