TextInput does not blur in Android 8.1 with react native 0.79+

[dlalas]

Description

TextInput does not blur in Android 8.1 with react native 0.79+ when clicked outside of the input anywhere. Though the keyboard closes. More specifically i have 2 text inputs if i try to blur the second one it will focus the first one without opening the keyboard.

Steps to reproduce

1. Just clean build a react native template with with react native 0.79+. Even with the latest one 0.79.2

React Native Version

0.79.2

Affected Platforms

Runtime - Android

Output of npx @react-native-community/cli info

System:
  OS: Windows 11 10.0.26100
  CPU: "(16) x64 AMD Ryzen 7 5800X 8-Core Processor             "
  Memory: 23.30 GB / 63.92 GB
Binaries:
  Node:
    version: 23.9.0
    path: C:\Program Files\nodejs\node.EXE
  Yarn: Not Found
  npm:
    version: 10.9.2
    path: C:\Program Files\nodejs\npm.CMD
  Watchman: Not Found
SDKs:
  Android SDK: Not Found
  Windows SDK: Not Found
IDEs:
  Android Studio: Not Found
  Visual Studio: Not Found
Languages:
  Java:
    version: 17.0.8.1
    path: /cygdrive/c/Program Files/Eclipse Adoptium/jdk-17.0.8.101-hotspot/bin/javac
  Ruby: Not Found
npmPackages:
  "@react-native-community/cli":
    installed: 18.0.0
    wanted: 18.0.0
  react:
    installed: 19.0.0
    wanted: 19.0.0
  react-native:
    installed: 0.79.2
    wanted: 0.79.2
  react-native-windows: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: Not found
  newArchEnabled: Not found

Stacktrace or Logs

Nothing is logged in logcat.

MANDATORY Reproducer

.

Screenshots and Videos

[react-native-bot]

[!WARNING] Missing reproducer: We could not detect a reproducible example in your issue report. Reproducers are mandatory and we can accept only one of those as a valid reproducer:

• For majority of bugs: send us a Pull Request with the RNTesterPlayground.js edited to reproduce your bug.
• If your bug is UI related: a Snack
• If your bug is build/upgrade related: a project using our Reproducer Template

You can read more about about it on our website: How to report a bug.

[cortinico]

TextInput does not blur in Android 8.1 with react native 0.79+ when clicked outside of the input anywhere. Though the keyboard closes. More specifically i have 2 text inputs if i try to blur the second one it will focus the first one without opening the keyboard.

Can you explain better? What do you mean with "TextInput does not blur"?

[dlalas]

The cursor pointer does not leave the first text input that finds in the screen.

[cortinico]

The cursor pointer does not leave the first text input that finds in the screen.

Can you share a video?

[dlalas]

No i dont know why. I will try later. The recreation is very easy. This is a clean react native template. You just have to run it on Android 8.1 device or even a virtual device. Add 2 TextInput and you will see that when you try to click outside the box the cusor pointer doesnt hide and even you try it in the 2nd 3rd input the cursor will move to first input of the screen.

[dlalas]

On both architectures.

[cortinico]

No i dont know why. I will try later. The recreation is very easy

Looking forward to see the video

[dlalas]

https://github.com/user-attachments/assets/3b445d5f-163d-441e-909d-5d6c525e958a

[cortinico]

Thanks for sharing the video @dlalas. What would be the expected behavior instead?

[dlalas]

The expected behavior should just be to blur the previously selected input and hide the cursor and not focus the first input of the screen (this is so weird). This is a same video on an Android 15

https://github.com/user-attachments/assets/5bf8010f-db05-43e9-b65f-59d4e5b31b51

[cortinico]

Ok so the issue is that the first TextInput is re-gaining the focus after you type on the first one. This happens only on Android 8.1. Correct?

[dlalas]

Yes only happening in Android 8.1 and only for react-native 0.79+

[goege64]

ran into this same issue! on an android 7.1 its especially a problem inside <ScrollView>s, since it blocks any interaction with the content inside due to the focus being forced into the <TextInput> i was able to fix it for now by switching the useEditTextStockAndroidFocusBehavior feature flag to false, which enables back some calls to setFocusableInTouchMode(false) and stops android from forcing this, but it seems this flag was removed a few days ago

edit: another repro, if necessary: https://github.com/goege64/reproducer-text-input-focus

[cortinico]

Thanks for the heads up @goege64

@joevilches can you look into this issue as you worked on useEditTextStockAndroidFocusBehavior ?

[joevilches]

@cortinico oh no! Yeah let me take a look and see if those changes broke something

[marcel-happyfloat]

Oh, I think I ran into this issue as well! Glad to see it’s already been reported—I initially thought it was something caused by my use of the react-native-screens or reanimated beta versions. But after looking more closely, I realized the input stays focused, which prevents interaction with other elements inside the ScrollView. Definitely a significant issue. But no worries—these things happen (and it might not even be related to your change). @joevilches

My test phone is on Android 8.0.0. Didn't experience this issue in my newer emulators.

[marcel-happyfloat]

@goege64 how did you set this feature flag?

[goege64]

@marcel-happyfloat I added this to my MainApplication.kt

import com.facebook.react.internal.featureflags.ReactNativeFeatureFlags
import com.facebook.react.internal.featureflags.ReactNativeNewArchitectureFeatureFlagsDefaults

and at the end of the onCreate function

ReactNativeFeatureFlags.dangerouslyForceOverride(object : ReactNativeNewArchitectureFeatureFlagsDefaults() {
  override fun useEditTextStockAndroidFocusBehavior(): Boolean = false
})

not sure if this causes other problems, because it does say dangerously, but on at least on 0.79 using the new architecture the result is ok from what i can tell

[marcel-happyfloat]

@goege64 Thanks, it works! But I’m now really noticing the difference on newer Android devices — I have to tap twice to trigger something like the reaction modal in my chat scrollview: once to remove focus, and once for the actual action. It used to work instantly before applying this patch, but it’s definitely better this way than the other way around 😄

[joevilches]

Update: checked yesterday and can confirm a repro on 8.1. From the looks of it the versions below also seem affected (8.0 and 7.1) but I didn't test those. When I was developing this initially I was on a much later version, which I do not see a repro on, so newer versions are not affected, although I'm not sure where the cutoff is exactly.

I'm out today, but next week will dig into this a little more. I haven't developed non-RN android on a version this early, so not sure if this is stock android behavior for edit text, or there is some RN code causing this. That feature flag basically just allows Android to focus text inputs to allow for things like keyboard navigation into text inputs. So it could be that android just wants to focus the first text view at all points which seems weird, but unsure yet.

I have to tap twice to trigger something like the reaction modal in my chat scrollview: once to remove focus, and once for the actual action. It used to work instantly before applying this patch, but it’s definitely better this way than the other way around 😄

@marcel-happyfloat to clarify, are you saying setting this feature flag to false cause this problem? Or updating to this version before the feature flag swap causes this?

[marcel-happyfloat]

@joevilches Yes, I believe so. Previously, before setting this flag to false (both RN v79.2), the input retained focus, but it still immediately triggered other interactions — unlike on the older devices. Not sure if this is intended behavior or not...

[joevilches]

@marcel-happyfloat interesting. When that feature flag is false it should go back to behavior that has existed for a while in that edit text class so there may be something else at play as well. I'll keep an eye out.

Do you mind showing me a video of what you are seeing? Would help me visualize some things.

[marcel-happyfloat]

@joevilches sorry for the confusion. I think it is back to the expected behavior (same as iOS now), when setting this flag to false.

Just tested some more and I think the current solution is also wrong for newer android phones. The difference seems to be (at least in the emulator) if the keyboard is not showing (e.g. external keyboard).

// FLAG=FALSE

// Keyboard showing or not showing (doesn't matter)

// Correct behavior? (same as iOS). Works on old and new android versions.
- focus the input
- click outside (will not trigger other pressables)
- focus is lost
- next click will trigger other pressables

// FLAG=TRUE

// Keyboard NOT showing

// Wrong behavior, but "works" for newer androids? 
- focus the input
- click outside (triggers pressables immediately) 
- ?? still focused

// Keyboard showing/open

// Correct behavior (same as iOS), but only for newer androids, can't click anything on older android phones, focus never lost
- focus the input
- click outside (will not trigger other pressables)
- focus is lost
- next click will trigger other pressables

[joevilches]

UPDATE: So I found out that the bug is coming from the clearFocus() call we make, which calls into super.clearFocus() which is https://developer.android.com/reference/android/view/View#clearFocus(). If you read the note there it says:

When not in touch-mode, the framework will try to give focus to the first focusable View from the top after focus is cleared. Hence, if this View is the first from the top that can take focus, then all callbacks related to clearing focus will be invoked after which the framework will give focus to this view.

I assume on earlier versions of Android there is a bug or feature where that note happens in touch-mode as well. The feature flag will enable behavior that just locks focusability for edit text components if its not from JS. So this auto focus call that comes from android would not do anything and is why that flag fixes things. This is problematic however because it also means we cannot use a hardware keyboard to focus this, which is what I was originally trying to fix. Gonna try to think of a solution that fixes both tomorrow.

[joevilches]

ok #51302 should fix this while also letting hardware keyboards work. I think I need to revert the feature flag removal and pick that into 0.80 though so there is a fix for this issue on all versions (since this one is slated for 0.81)

[jvenene]

I think I need to revert the feature flag removal and pick that into 0.80 though so there is a fix for this issue on all versions ...

Would it make sense to also pick that onto 0.79 since that's where the issue was first reported?

[joevilches]

@jvenene yeah good callout, I'll aim to pick the fix into 0.79

[goege64]

Tried out 0.80.0-rc.3 and the issue does seem to be fixed! thank you.

[cortinico]

Closing as this will be fixed in the upcoming 0.80 release

[jvenene]

@jvenene yeah good callout, I'll aim to pick the fix into 0.79

Is this still the plan? Just wondering since the issue is closed now, and I didn't see a pick onto 0.79.