IndexOutOfBoundsException when using Google Indic Keyboard with RN 0.53.0 #17974
Comments
|
@SuhairZain can you post the stack trace? |
|
@joshyhargreaves Here's all the data that I have about the crash: {
"client": {
"clientUrl": "https://github.com/MindscapeHQ/raygun4android",
"name": "Raygun4Android",
"version": "3.0.0"
},
"context": {
"identifier": "xxxxxxxxxxxxxxxxx"
},
"environment": {
"architecture": "armeabi-v7a",
"availablePhysicalMemory": 620,
"availableVirtualMemory": 0,
"board": "msm8937",
"brand": "Xiaomi",
"currentOrientation": "Portrait",
"deviceCode": "land",
"deviceName": "Redmi 3S",
"diskSpaceFree": 5861,
"locale": "en_US",
"oSVersion": "6.0.1",
"osSDKVersion": "23",
"processorCount": 8,
"totalPhysicalMemory": 2843,
"totalVirtualMemory": 0,
"utcOffset": 5.0,
"windowsBoundHeight": 1280,
"windowsBoundWidth": 720
},
"error": {
"className": "java.lang.IndexOutOfBoundsException",
"message": "IndexOutOfBoundsException: charAt: -1 < 0",
"stackTrace": [
{
"className": "android.text.SpannableStringBuilder",
"fileName": "SpannableStringBuilder.java",
"lineNumber": 117,
"methodName": "charAt"
},
{
"className": "com.facebook.react.views.textinput.ReactEditTextInputConnectionWrapper",
"fileName": "ReactEditTextInputConnectionWrapper.java",
"lineNumber": 104,
"methodName": "setComposingText"
},
{
"className": "com.android.internal.view.IInputConnectionWrapper",
"fileName": "IInputConnectionWrapper.java",
"lineNumber": 340,
"methodName": "executeMessage"
},
{
"className": "com.android.internal.view.IInputConnectionWrapper$MyHandler",
"fileName": "IInputConnectionWrapper.java",
"lineNumber": 78,
"methodName": "handleMessage"
},
{
"className": "android.os.Handler",
"fileName": "Handler.java",
"lineNumber": 102,
"methodName": "dispatchMessage"
},
{
"className": "android.os.Looper",
"fileName": "Looper.java",
"lineNumber": 157,
"methodName": "loop"
},
{
"className": "android.app.ActivityThread",
"fileName": "ActivityThread.java",
"lineNumber": 5555,
"methodName": "main"
},
{
"className": "java.lang.reflect.Method",
"fileName": "Method.java",
"lineNumber": -2,
"methodName": "invoke"
},
{
"className": "com.android.internal.os.ZygoteInit$MethodAndArgsCaller",
"fileName": "ZygoteInit.java",
"lineNumber": 745,
"methodName": "run"
},
{
"className": "com.android.internal.os.ZygoteInit",
"fileName": "ZygoteInit.java",
"lineNumber": 635,
"methodName": "main"
}
]
},
"machineName": "Redmi 3S",
"request": {
"iPAddress": [
"xxxxxxxxxxxxx"
],
"networkConnectivityState": "Connected - WiFi"
},
"tags": [
"UnhandledException"
],
"user": {
"identifier": "xxxxxxxxxxx"
},
"version": "xxxxxxxxxxx",
"OccurredOn": "2018-02-14T04:27:24Z"
} |
|
@SuhairZain are you able to reproduce on a simulator? Or is this a device? |
|
@joshyhargreaves This is a device. I tried to reproduce it on an emulator but it didn't have the Indic keyboard. If it'd help you, I'll try to install the keyboard on an emulator and see. |
|
@SuhairZain I installed the Indic keyboard on an emulator by downloading the APK and installing with Could you try the fix that I just pushed to a branch, you can either update your react-native dependency in your |
|
@joshyhargreaves I was unable to reproduce it on an emulator as well. I think you wouldn't be able to reproduce this on a device either. Seems like I'm running an old version of Google Indic keyboard on my device, even though I have auto-updates on. The version I have on the emulator is 3.2.5.164561151-x86, whereas on my device it's 3.2.1.127799310-armeabi-v7a. I think it'd be wise for me to not upgrade to the latest version of the keyboard on the device since it may be difficult to revert to the old version. What do you suggest? |
|
@SuhairZain could you build your repo-project for your device with the changes I just pushed and let me know if it still crashes on your device? |
|
I greatly suspect it will have fixed the issue. For the |
|
But this issue doesn't appear on the older version of RN, at least as far
as 0.47.1. It's very likely that some change since then had something to do
with this edge case. Is it worth looking at?
…On Feb 15, 2018 10:20 PM, "Josh Hargreaves" ***@***.***> wrote:
I greatly suspect it will have fixed the issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17974 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFAbArLzBnzTHHpP8uzxuQ0N752uS2NZks5tVGBAgaJpZM4SEzn2>
.
|
|
@SuhairZain, I know what the issue was as I who introduced it while implementing onKeyPress for Android. If you look at my earlier comment you can pull the fix from my branch and test it. |
|
@joshyhargreaves I'm sorry. I was replying via email and didn't see your 1st comment. I'll check right away. |
|
@joshyhargreaves I'm unable to build a new project created using the code you posted above. Getting the following error: |
|
@SuhairZain sorry, that's my bad, I forgot that android needs to be built from source. |
|
@joshyhargreaves In that case, I'll build it from source and try tomorrow. I see that it'll take some time. |
|
You can build react-native in-place in |
|
I'll try building the APK this way and sending it over to my team that is onsite. I won't hear back from them until tomorrow afternoon/Monday most likely, but I'll let you know. |
|
@ccdwyer, sounds good, thank you, and we can go from there. Sorry about this crash, it was a definite oversight on my part. |
|
@joshyhargreaves Pardon my ignorance, where am I supposed to run the ./gradlew :ReactAndroid:installArchives command? I tried running that inside my android folder and got:
|
|
@joshyhargreaves @ccdwyer I'm getting the following error when trying to build from source as described in Building React Native from source. If you're able to build from source, would it be possible for you to use your fork with the example repo I had provided and send me a universal APK? |
|
@ccdwyer, you have to run this from within node_modules/React-Native. When React Native is published to npm, it runs this command and pushes the built assets as part of the package. As I’ve just pushed this to a branch, and including this repository as a git dependency; this step hasn’t happened. |
|
What I didn’t have time to do, was figure out the location of these built assets, and force add them to git and push them. I don’t have my laptop with me and I’m away this weekend, otherwise I’d do it! |
|
@joshyhargreaves I get it. However, it seems that Play Store finally decided to update Google Indic keyboard on my device yesterday. I'm no longer having crashes. Will have to find an older version and install it on an emulator using adb. Where did you download the latest APK from? |
|
@joshyhargreaves Do you think it might be possible for you to add those assets? I encountered some issues trying to build react native myself, so I haven't been able to test the change. |
|
@ccdwyer no problem, I will do this evening as currently AFK! |
|
@joshyhargreaves Thanks! |
|
@ccdwyer I've pushed the built assets: update the npm dependency to |
|
@joshyhargreaves Thanks! I built an APK with it and sent it over to my team. |
|
@joshyhargreaves Just letting you know I didn't forget about this. My team is supposed to test the APK with the fix tomorrow. Things move a little slower in the midwest. :) |
|
@ccdwyer any news? |
|
@joshyhargreaves Nothing yet, pinged them again for a response. |
|
@joshyhargreaves It appears that the crash is gone for us with your change. Thanks! |
|
👋 @joshyhargreaves I think that the issue OP posted is actually just one of the ways the bug can manifest itself (and #17922 is another) - this weekend we released the latest update to our app with RN 0.53 and I have 3 different crash reports that seems to be all related to the same root issue: Sadly I can't post much more of the stacktrace since it comes from the minified prod version; but I strongly believe the fix you linked earlier will solve these crashes too (I can't dive deeper into creating a repro or doing a new release pointing at your branch because of higher prior tasks this week). It's still quite a small 'surface', since we are talking about a precise set of actions on a custom keyboard on Android (overall, we got less than 20 crashes reported by up to 6 users - which is a .00x% of our userbase) so no rush, but are you planning on doing a PR with it? I don't think, since it's already late Feb, that it would be merged & cherry picked into a new 0.53.x release, but I think it would be possible to have it in 0.54 💪 (ps: ofc if there's anything that I can do to help let me know!) |
|
Hey @kelset, thank you for the crash reports, I had actually suspected that their might be a few different ways that this bug could manifest itself. Looking at your stack traces, I’m not actually that confident that that the fix I posted previously would fix these, as it seems like the reference to the wrapped InputConnection can turn null, but I will do a bit of thinking/researching over the next few hours. I will absolutely put in a pull request for this, I think it may be a good idea also to only enable this codepath if using ‘onKeyPress’, and so I will have a look at that also! Let’s just get this fixed, thanks again for the crash reports. |
|
@kelset it looks like you need to guard against null being returned by It would be helpful to know exactly the particular cases when edit: but I'd say, in my judgement, adding the |
|
Hey, thanks for the clarification. |
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
|
This should be addressed in, so I will close: b60a727. Please re-open if the problem somehow persists. |
|
I'lll re-open until we know if this commit make it into the |
|
I'll close it as I am cherry picking it right now. |
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
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
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
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
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
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
Is this a bug report?
Yes
Have you read the Contributing Guidelines?
Yes
Environment
Environment:
OS: macOS High Sierra 10.13.2
Node: 8.4.0
Yarn: 0.27.5
npm: 5.3.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
Target Platform: Android (6.0.1)
Steps to Reproduce
react-native init. (Most likely exists for projects created using other methods as well, didn't check.)a. Create a TextInput with no additional props (or switch to the master branch of the provided repo).
a. Type an emoji and press the backspace twice.
a. Create a TextInput with autoCorrect={false} (or switch to the auto-correct branch of the provided repo).
a. Type any character and press the backspace once.
Expected Behavior
The emojis and characters get cleared with no crashes
Actual Behavior
The app crashes on clearing the emojis, with no additional props set on the TextInput
The app crashes on clearing the last character in case autoCorrect={false} is set
Reproducible Demo
https://github.com/SuhairZain/react-native-gindic-keyboard-crash
The
masterbranch crashes when deleting an emoji characterThe
auto-correctbranch crashes when deleting the last character in the inputThe reason that I've created this issue here rather than on the Google Indic keyboard repo is that I can confirm that this bug does not exist with 0.47.1, which is the version our app was on before we upgraded. This is a bug that was introduced in one of the versions from then to 0.53.0.
The text was updated successfully, but these errors were encountered: