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

TextInput secureTextEntry crashing on Android custom keyboard? #17922

Closed
apparition47 opened this issue Feb 9, 2018 · 15 comments
Closed

TextInput secureTextEntry crashing on Android custom keyboard? #17922

apparition47 opened this issue Feb 9, 2018 · 15 comments
Labels
Resolution: Locked This issue was locked by the bot.

Comments

@apparition47
Copy link

Is this a bug report?

Yes.

Have you read the Contributing Guidelines?

Yes.

Environment

Environment:
OS: macOS High Sierra 10.13.3
Node: 9.4.0
Yarn: 1.0.2
npm: 5.6.0
Watchman: 4.9.0
Xcode: Xcode 9.2 Build version 9C40b
Android Studio: 3.0 AI-171.4443003

Packages: (wanted => installed)
react: ^16.2.0 => 16.2.0
react-native: 0.53.0 => 0.53.0

Tested on Devices:

  • Plus One Japan Limited FTJ161B (Android 6.0, API 23)
  • Samsung Galaxy Note 8 (Android 7.1.1)

Steps to Reproduce

Using com.justsystems.atokmobile.tv.service custom keyboard then typing into a <TextInput secureTextEntry={true}> field yields the following crash:

13:16:19.098 4410-4410/com.example.dev E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.example.dev, PID: 4410
java.lang.IndexOutOfBoundsException: charAt: -1 < 0
at android.text.SpannableStringBuilder.charAt(SpannableStringBuilder.java:122)
at com.facebook.react.views.textinput.ReactEditTextInputConnectionWrapper.setComposingText(ReactEditTextInputConnectionWrapper.java:104)
at com.android.internal.view.IInputConnectionWrapper.executeMessage(IInputConnectionWrapper.java:340)
at com.android.internal.view.IInputConnectionWrapper$MyHandler.handleMessage(IInputConnectionWrapper.java:78)
at android.os.Handler.dispatchMessage(Handler.java:111)
at android.os.Looper.loop(Looper.java:207)
at android.app.ActivityThread.main(ActivityThread.java:5728)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:789)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:679)

  1. Focus the <TextInput>
  2. On the soft keyboard, hitting the "1" key and the "backspace" key in alternation seems to cause the crash although it seems random.

Issue isn't present with the Google AOSP keyboard. Seems to happen only with this keyboard and the secureTextEntry={true}.

Expected Behavior

This should work on all keyboards.

Actual Behavior

feb-09-2018 13-50-14

@joshjhargreaves
Copy link
Contributor

This looks to be as a result of the onKeyPress functionality which I worked on adding for 0.53. Seems related to this issue: #17974. I will have a look into this.

@joshjhargreaves
Copy link
Contributor

joshjhargreaves commented Feb 15, 2018

(As your stack trace suggests), specifically the problem is to do with this line: https://github.com/facebook/react-native/blob/0.53-stable/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactEditTextInputConnectionWrapper.java#L104. At the very least, this should be guarded against. I'm looking into why there seems to be a race condition. Will post updates.

@ccdwyer
Copy link

ccdwyer commented Feb 15, 2018

I'm seeing this issue come up now, with React Native 0.53 and Android 6.0.1 Zebra tablets. Any time they press backspace the app is crashing.

@joshjhargreaves
Copy link
Contributor

@ccdwyer same stack trace?

@ccdwyer
Copy link

ccdwyer commented Feb 15, 2018

@joshyhargreaves I'm not sure, I won't have access to one of the devices until Monday. I'm just hearing it from a co-worker that is on location (it's happening at a customer site). Any time they press backspace the app crashes. They are using the Google Keyboard English (US). Their Samsung Android 7.1.1 devices are working fine, though.

@joshjhargreaves
Copy link
Contributor

Thank you, I do suspect that it's the same stack trace.

@joshjhargreaves
Copy link
Contributor

joshjhargreaves commented Feb 15, 2018

I've pushed a fix to a branch on my react-native fork, if not too much trouble would you mind testing to see if it fixes your issues?

You can test in your projects by updating your package.json dependency for react-native to git+https://github.com/joshyhargreaves/react-native#89eaafe6aa9f98a32ae48a400ebfea8295918bb6, and running npm/yarn install

This is the 0.53 branch with this one additional commit.

@joshjhargreaves
Copy link
Contributor

joshjhargreaves commented Feb 15, 2018

I have just remembered that react-native is not built from source on Android. This can be fiddly to setup if you have no already set it up, but you can build react-native downloaded in node_modules by running the command ./gradlew :ReactAndroid:installArchives. I can push the built assets to the branch also to be helpful, and that would mean updating the NPM dependency would work as expected.

@apparition47
Copy link
Author

apparition47 commented Feb 16, 2018

You weren't kidding about compiling being fiddly. Ran into this error: Could not get unknown property 'repositoryUrl' for project ':ReactAndroid' of type org.gradle.api.Project. and this other NDK error (have to use the exact android-ndk-r10e NDK version specified on React Native's docs).

Anyhow, I tested your commit and it seems to fix the Force Close issue I was having. Thanks!

@joshjhargreaves
Copy link
Contributor

@apparition47 thank you for checking this out and providing a detailed issue! I haven’t managed to reproduce this issue yet (on a simulator) but will try on a device as soon as I can.

So I don’t know much about the point release process, but I think this fix should be eligible to be merged into 0.53 (as well as master). I’ll work on getting this done

@laurent22
Copy link

I'm having the same issue since I've upgraded to RN 0.53. On Xperia, when I use the keyboard motion feature it crashes. If that can help here is the stack trace:

02-17 22:02:21.512 16850 16850 E AndroidRuntime: FATAL EXCEPTION: main
02-17 22:02:21.512 16850 16850 E AndroidRuntime: Process: net.cozic.joplin, PID: 16850
02-17 22:02:21.512 16850 16850 E AndroidRuntime: java.lang.IndexOutOfBoundsException: charAt: -1 < 0
02-17 22:02:21.512 16850 16850 E AndroidRuntime:        at android.text.SpannableStringBuilder.charAt(SpannableStringBuilder.java:122)
02-17 22:02:21.512 16850 16850 E AndroidRuntime:        at com.facebook.react.views.textinput.ReactEditTextInputConnectionWrapper.setComposingText(ReactEditTextInputConnectionWrapper.java:104)
02-17 22:02:21.512 16850 16850 E AndroidRuntime:        at com.android.internal.view.IInputConnectionWrapper.executeMessage(IInputConnectionWrapper.java:408)
02-17 22:02:21.512 16850 16850 E AndroidRuntime:        at com.android.internal.view.IInputConnectionWrapper$MyHandler.handleMessage(IInputConnectionWrapper.java:93)
02-17 22:02:21.512 16850 16850 E AndroidRuntime:        at android.os.Handler.dispatchMessage(Handler.java:102)
02-17 22:02:21.512 16850 16850 E AndroidRuntime:        at android.os.Looper.loop(Looper.java:241)
02-17 22:02:21.512 16850 16850 E AndroidRuntime:        at android.app.ActivityThread.main(ActivityThread.java:6274)
02-17 22:02:21.512 16850 16850 E AndroidRuntime:        at java.lang.reflect.Method.invoke(Native Method)
02-17 22:02:21.512 16850 16850 E AndroidRuntime:        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
02-17 22:02:21.512 16850 16850 E AndroidRuntime:        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)

@laurent22
Copy link

The keyboard feature I'm using is like Swype where you swipe your finger to type words. So I'm not familiar with the source code but I'm guessing the action of swiping is triggering some event, but since the words is not fully written yet some variable doesn't have the expected value.

Maybe something to look at basically. I don't know if it can be tested in Android Simulator though.

facebook-github-bot pushed a commit that referenced this issue Feb 27, 2018
Summary:
There appear to be two different types of crashes related to the recent addition of `onKeyPress` on Android introduce in `0.53`. This PR addresses the cause of both of them.

Firstly, it seems possible to get an `indexOutOfBoundsException` with some 3rd-party keyboards as observed in #17974 & #17922. I have simplified the backspace determining logic slightly, and also put in an explicit check for zero case so it is not possible to get an indexOutOfBoundsException & it should make sense in the context of the onKeyPress logic.

Secondly, it appears that `EditText#onCreateInputConnection` can return null. In this case, if we set `null` to be the target of our subclass of `ReactEditTextInputConnectionWrapper`, we will see the crashes as seen [here](#17974 (comment)), whereby any of methods executed in the `InputConnection` interface can result in a crash. It's hard to reason about the state when `null` is returned from `onCreateInputConnection`, however I would might reason that any soft keyboard input cannot update the `EditText` with a `null` `input connection`, as there is no way of interfacing with the `EditText`. I'm am not sure, if there is a later point where we might return/set this input connection at a later point? As without the `InputConnection` onKeyPress will not work. But for now, this will fix this crash at least.

I have not managed to reproduce these crashes myself yet, but users have confirmed that the `indexOutOfBounds` exception is fixed with the 'zero' case and has been confirmed on the respective issues #17974 (comment).

For the `null` inputConnection target case, I have verified that explicitly setting the target as null in the constructor of `onCreateInputConnection` results in the same stack trace as the one linked. Here is also a [reference](https://github.com/stripe/stripe-android/pull/392/files#diff-6cc1685c98457d07fd4e2dd83f54d5bb) to the same issue closed with the same fix for another project on github.

It is also important to verify that the behavior of `onKeyPress` still functions the same after this change, which can be verified by running the RNTesterProject and the `KeyboardEvents` section in `InputText`.
The cases to check that I think are important to check are:
- Cursor at beginning of input & backspace
- Return key & return key at beginning of input
- Select text then press delete
- Selection then press a key
- Space key
- Different keyboard types

This should not be a breaking change.

 [ANDROID] [BUGFIX] [TextInput] - Fixes crashes with TextInput introduced in 0.53.
Closes #18114

Differential Revision: D7099570

Pulled By: hramos

fbshipit-source-id: 75b2dc468c1ed398a33eb00487c6aa14ae04e5c2
@joshjhargreaves
Copy link
Contributor

I have addressed the crash in b60a727 which is now in master. I will close this Issue and leave #17974 open until we know if the commit will make into the 0.54 release.

@laurent22
Copy link

Thanks @joshyhargreaves. It would be nice if there was bug fix releases in RN though, because while this bug will be fixed in 0.54, I expect there will be new ones too, which means upgrade is never possible. I'm still at 0.49 because 0.51 had a crash in iOS, and 0.53 this crash in Android.

grabbou pushed a commit that referenced this issue Mar 1, 2018
Summary:
There appear to be two different types of crashes related to the recent addition of `onKeyPress` on Android introduce in `0.53`. This PR addresses the cause of both of them.

Firstly, it seems possible to get an `indexOutOfBoundsException` with some 3rd-party keyboards as observed in #17974 & #17922. I have simplified the backspace determining logic slightly, and also put in an explicit check for zero case so it is not possible to get an indexOutOfBoundsException & it should make sense in the context of the onKeyPress logic.

Secondly, it appears that `EditText#onCreateInputConnection` can return null. In this case, if we set `null` to be the target of our subclass of `ReactEditTextInputConnectionWrapper`, we will see the crashes as seen [here](#17974 (comment)), whereby any of methods executed in the `InputConnection` interface can result in a crash. It's hard to reason about the state when `null` is returned from `onCreateInputConnection`, however I would might reason that any soft keyboard input cannot update the `EditText` with a `null` `input connection`, as there is no way of interfacing with the `EditText`. I'm am not sure, if there is a later point where we might return/set this input connection at a later point? As without the `InputConnection` onKeyPress will not work. But for now, this will fix this crash at least.

I have not managed to reproduce these crashes myself yet, but users have confirmed that the `indexOutOfBounds` exception is fixed with the 'zero' case and has been confirmed on the respective issues #17974 (comment).

For the `null` inputConnection target case, I have verified that explicitly setting the target as null in the constructor of `onCreateInputConnection` results in the same stack trace as the one linked. Here is also a [reference](https://github.com/stripe/stripe-android/pull/392/files#diff-6cc1685c98457d07fd4e2dd83f54d5bb) to the same issue closed with the same fix for another project on github.

It is also important to verify that the behavior of `onKeyPress` still functions the same after this change, which can be verified by running the RNTesterProject and the `KeyboardEvents` section in `InputText`.
The cases to check that I think are important to check are:
- Cursor at beginning of input & backspace
- Return key & return key at beginning of input
- Select text then press delete
- Selection then press a key
- Space key
- Different keyboard types

This should not be a breaking change.

 [ANDROID] [BUGFIX] [TextInput] - Fixes crashes with TextInput introduced in 0.53.
Closes #18114

Differential Revision: D7099570

Pulled By: hramos

fbshipit-source-id: 75b2dc468c1ed398a33eb00487c6aa14ae04e5c2
@arash-hacker
Copy link

i have issue with onChangeText ...
when typing and delete texts app crash on real android but in emulator it's ok

cpirich pushed a commit to tracemeinc/react-native that referenced this issue Mar 22, 2018
Summary:
There appear to be two different types of crashes related to the recent addition of `onKeyPress` on Android introduce in `0.53`. This PR addresses the cause of both of them.

Firstly, it seems possible to get an `indexOutOfBoundsException` with some 3rd-party keyboards as observed in facebook#17974 & facebook#17922. I have simplified the backspace determining logic slightly, and also put in an explicit check for zero case so it is not possible to get an indexOutOfBoundsException & it should make sense in the context of the onKeyPress logic.

Secondly, it appears that `EditText#onCreateInputConnection` can return null. In this case, if we set `null` to be the target of our subclass of `ReactEditTextInputConnectionWrapper`, we will see the crashes as seen [here](facebook#17974 (comment)), whereby any of methods executed in the `InputConnection` interface can result in a crash. It's hard to reason about the state when `null` is returned from `onCreateInputConnection`, however I would might reason that any soft keyboard input cannot update the `EditText` with a `null` `input connection`, as there is no way of interfacing with the `EditText`. I'm am not sure, if there is a later point where we might return/set this input connection at a later point? As without the `InputConnection` onKeyPress will not work. But for now, this will fix this crash at least.

I have not managed to reproduce these crashes myself yet, but users have confirmed that the `indexOutOfBounds` exception is fixed with the 'zero' case and has been confirmed on the respective issues facebook#17974 (comment).

For the `null` inputConnection target case, I have verified that explicitly setting the target as null in the constructor of `onCreateInputConnection` results in the same stack trace as the one linked. Here is also a [reference](https://github.com/stripe/stripe-android/pull/392/files#diff-6cc1685c98457d07fd4e2dd83f54d5bb) to the same issue closed with the same fix for another project on github.

It is also important to verify that the behavior of `onKeyPress` still functions the same after this change, which can be verified by running the RNTesterProject and the `KeyboardEvents` section in `InputText`.
The cases to check that I think are important to check are:
- Cursor at beginning of input & backspace
- Return key & return key at beginning of input
- Select text then press delete
- Selection then press a key
- Space key
- Different keyboard types

This should not be a breaking change.

 [ANDROID] [BUGFIX] [TextInput] - Fixes crashes with TextInput introduced in 0.53.
Closes facebook#18114

Differential Revision: D7099570

Pulled By: hramos

fbshipit-source-id: 75b2dc468c1ed398a33eb00487c6aa14ae04e5c2
fcangialosi pushed a commit to inizio-inc/react-native that referenced this issue Jul 17, 2018
Summary:
There appear to be two different types of crashes related to the recent addition of `onKeyPress` on Android introduce in `0.53`. This PR addresses the cause of both of them.

Firstly, it seems possible to get an `indexOutOfBoundsException` with some 3rd-party keyboards as observed in facebook#17974 & facebook#17922. I have simplified the backspace determining logic slightly, and also put in an explicit check for zero case so it is not possible to get an indexOutOfBoundsException & it should make sense in the context of the onKeyPress logic.

Secondly, it appears that `EditText#onCreateInputConnection` can return null. In this case, if we set `null` to be the target of our subclass of `ReactEditTextInputConnectionWrapper`, we will see the crashes as seen [here](facebook#17974 (comment)), whereby any of methods executed in the `InputConnection` interface can result in a crash. It's hard to reason about the state when `null` is returned from `onCreateInputConnection`, however I would might reason that any soft keyboard input cannot update the `EditText` with a `null` `input connection`, as there is no way of interfacing with the `EditText`. I'm am not sure, if there is a later point where we might return/set this input connection at a later point? As without the `InputConnection` onKeyPress will not work. But for now, this will fix this crash at least.

I have not managed to reproduce these crashes myself yet, but users have confirmed that the `indexOutOfBounds` exception is fixed with the 'zero' case and has been confirmed on the respective issues facebook#17974 (comment).

For the `null` inputConnection target case, I have verified that explicitly setting the target as null in the constructor of `onCreateInputConnection` results in the same stack trace as the one linked. Here is also a [reference](https://github.com/stripe/stripe-android/pull/392/files#diff-6cc1685c98457d07fd4e2dd83f54d5bb) to the same issue closed with the same fix for another project on github.

It is also important to verify that the behavior of `onKeyPress` still functions the same after this change, which can be verified by running the RNTesterProject and the `KeyboardEvents` section in `InputText`.
The cases to check that I think are important to check are:
- Cursor at beginning of input & backspace
- Return key & return key at beginning of input
- Select text then press delete
- Selection then press a key
- Space key
- Different keyboard types

This should not be a breaking change.

 [ANDROID] [BUGFIX] [TextInput] - Fixes crashes with TextInput introduced in 0.53.
Closes facebook#18114

Differential Revision: D7099570

Pulled By: hramos

fbshipit-source-id: 75b2dc468c1ed398a33eb00487c6aa14ae04e5c2
fcangialosi pushed a commit to inizio-inc/react-native that referenced this issue Jul 18, 2018
Summary:
There appear to be two different types of crashes related to the recent addition of `onKeyPress` on Android introduce in `0.53`. This PR addresses the cause of both of them.

Firstly, it seems possible to get an `indexOutOfBoundsException` with some 3rd-party keyboards as observed in facebook#17974 & facebook#17922. I have simplified the backspace determining logic slightly, and also put in an explicit check for zero case so it is not possible to get an indexOutOfBoundsException & it should make sense in the context of the onKeyPress logic.

Secondly, it appears that `EditText#onCreateInputConnection` can return null. In this case, if we set `null` to be the target of our subclass of `ReactEditTextInputConnectionWrapper`, we will see the crashes as seen [here](facebook#17974 (comment)), whereby any of methods executed in the `InputConnection` interface can result in a crash. It's hard to reason about the state when `null` is returned from `onCreateInputConnection`, however I would might reason that any soft keyboard input cannot update the `EditText` with a `null` `input connection`, as there is no way of interfacing with the `EditText`. I'm am not sure, if there is a later point where we might return/set this input connection at a later point? As without the `InputConnection` onKeyPress will not work. But for now, this will fix this crash at least.

I have not managed to reproduce these crashes myself yet, but users have confirmed that the `indexOutOfBounds` exception is fixed with the 'zero' case and has been confirmed on the respective issues facebook#17974 (comment).

For the `null` inputConnection target case, I have verified that explicitly setting the target as null in the constructor of `onCreateInputConnection` results in the same stack trace as the one linked. Here is also a [reference](https://github.com/stripe/stripe-android/pull/392/files#diff-6cc1685c98457d07fd4e2dd83f54d5bb) to the same issue closed with the same fix for another project on github.

It is also important to verify that the behavior of `onKeyPress` still functions the same after this change, which can be verified by running the RNTesterProject and the `KeyboardEvents` section in `InputText`.
The cases to check that I think are important to check are:
- Cursor at beginning of input & backspace
- Return key & return key at beginning of input
- Select text then press delete
- Selection then press a key
- Space key
- Different keyboard types

This should not be a breaking change.

 [ANDROID] [BUGFIX] [TextInput] - Fixes crashes with TextInput introduced in 0.53.
Closes facebook#18114

Differential Revision: D7099570

Pulled By: hramos

fbshipit-source-id: 75b2dc468c1ed398a33eb00487c6aa14ae04e5c2
artdent pushed a commit to triggr/react-native that referenced this issue Jul 19, 2018
Summary:
There appear to be two different types of crashes related to the recent addition of `onKeyPress` on Android introduce in `0.53`. This PR addresses the cause of both of them.

Firstly, it seems possible to get an `indexOutOfBoundsException` with some 3rd-party keyboards as observed in facebook#17974 & facebook#17922. I have simplified the backspace determining logic slightly, and also put in an explicit check for zero case so it is not possible to get an indexOutOfBoundsException & it should make sense in the context of the onKeyPress logic.

Secondly, it appears that `EditText#onCreateInputConnection` can return null. In this case, if we set `null` to be the target of our subclass of `ReactEditTextInputConnectionWrapper`, we will see the crashes as seen [here](facebook#17974 (comment)), whereby any of methods executed in the `InputConnection` interface can result in a crash. It's hard to reason about the state when `null` is returned from `onCreateInputConnection`, however I would might reason that any soft keyboard input cannot update the `EditText` with a `null` `input connection`, as there is no way of interfacing with the `EditText`. I'm am not sure, if there is a later point where we might return/set this input connection at a later point? As without the `InputConnection` onKeyPress will not work. But for now, this will fix this crash at least.

I have not managed to reproduce these crashes myself yet, but users have confirmed that the `indexOutOfBounds` exception is fixed with the 'zero' case and has been confirmed on the respective issues facebook#17974 (comment).

For the `null` inputConnection target case, I have verified that explicitly setting the target as null in the constructor of `onCreateInputConnection` results in the same stack trace as the one linked. Here is also a [reference](https://github.com/stripe/stripe-android/pull/392/files#diff-6cc1685c98457d07fd4e2dd83f54d5bb) to the same issue closed with the same fix for another project on github.

It is also important to verify that the behavior of `onKeyPress` still functions the same after this change, which can be verified by running the RNTesterProject and the `KeyboardEvents` section in `InputText`.
The cases to check that I think are important to check are:
- Cursor at beginning of input & backspace
- Return key & return key at beginning of input
- Select text then press delete
- Selection then press a key
- Space key
- Different keyboard types

This should not be a breaking change.

 [ANDROID] [BUGFIX] [TextInput] - Fixes crashes with TextInput introduced in 0.53.
Closes facebook#18114

Differential Revision: D7099570

Pulled By: hramos

fbshipit-source-id: 75b2dc468c1ed398a33eb00487c6aa14ae04e5c2
artdent pushed a commit to triggr/react-native that referenced this issue Jul 19, 2018
Summary:
There appear to be two different types of crashes related to the recent addition of `onKeyPress` on Android introduce in `0.53`. This PR addresses the cause of both of them.

Firstly, it seems possible to get an `indexOutOfBoundsException` with some 3rd-party keyboards as observed in facebook#17974 & facebook#17922. I have simplified the backspace determining logic slightly, and also put in an explicit check for zero case so it is not possible to get an indexOutOfBoundsException & it should make sense in the context of the onKeyPress logic.

Secondly, it appears that `EditText#onCreateInputConnection` can return null. In this case, if we set `null` to be the target of our subclass of `ReactEditTextInputConnectionWrapper`, we will see the crashes as seen [here](facebook#17974 (comment)), whereby any of methods executed in the `InputConnection` interface can result in a crash. It's hard to reason about the state when `null` is returned from `onCreateInputConnection`, however I would might reason that any soft keyboard input cannot update the `EditText` with a `null` `input connection`, as there is no way of interfacing with the `EditText`. I'm am not sure, if there is a later point where we might return/set this input connection at a later point? As without the `InputConnection` onKeyPress will not work. But for now, this will fix this crash at least.

I have not managed to reproduce these crashes myself yet, but users have confirmed that the `indexOutOfBounds` exception is fixed with the 'zero' case and has been confirmed on the respective issues facebook#17974 (comment).

For the `null` inputConnection target case, I have verified that explicitly setting the target as null in the constructor of `onCreateInputConnection` results in the same stack trace as the one linked. Here is also a [reference](https://github.com/stripe/stripe-android/pull/392/files#diff-6cc1685c98457d07fd4e2dd83f54d5bb) to the same issue closed with the same fix for another project on github.

It is also important to verify that the behavior of `onKeyPress` still functions the same after this change, which can be verified by running the RNTesterProject and the `KeyboardEvents` section in `InputText`.
The cases to check that I think are important to check are:
- Cursor at beginning of input & backspace
- Return key & return key at beginning of input
- Select text then press delete
- Selection then press a key
- Space key
- Different keyboard types

This should not be a breaking change.

 [ANDROID] [BUGFIX] [TextInput] - Fixes crashes with TextInput introduced in 0.53.
Closes facebook#18114

Differential Revision: D7099570

Pulled By: hramos

fbshipit-source-id: 75b2dc468c1ed398a33eb00487c6aa14ae04e5c2
@facebook facebook locked as resolved and limited conversation to collaborators Feb 27, 2019
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Feb 27, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Resolution: Locked This issue was locked by the bot.
Projects
None yet
Development

No branches or pull requests

6 participants