-
Notifications
You must be signed in to change notification settings - Fork 24.4k
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
Controlled TextInput broken for Chinese (and other languages) in v0.54 on iOS #18403
Comments
Great bug report! Thanks for organizing all of the reports. |
@danielsuo I created a PR #18456 to fix this issue. |
if it has prop value or defaultvalue,you can't input Chinese |
I updated the pull request and the sample app. |
I changed and tried again , but it doesn't work . Do you have the prop "defaultValue" like defaultValue=this.props.value ? I found it ok that using defaultValue="test" |
I tried 2 cases, and both of them seemed working.
|
I tried receiving defaultValue as prop, and it also seemed working.
|
Oh My fault . I appreciate your help !!! Thanks !! |
All right. Thank you! |
Works for me! Appreciate the quick fix! |
Thank you @danielsuo! |
This wasn't merged into 0.54.4 right? |
0.55.0 has this problem |
Currently the following comment provides the best solution |
Has this been fixed in 0.56? |
I checked it, at first glance Japanese input seems to work. But I using it rarely, so can't be totally sure. |
@tsangwailam withHandleHandWritingTextInput.js
And in another js use by
|
Not solved yet? Temporally hack code maybe not good to tackle on... |
I was facing the same issue.
And this.state.inputText returns exactly the same as what I can see from the screen. |
@kevinkevw, but most of times you need to set |
@vovkasm Ah yes you're right. I got your point. But the bug itself still not yet been fixed. Leaving it uncontrolled seems working fine in my case, I set the initial value by |
@ tsangwailam 唔该晒!! |
@tsangwailam In order to be compatible with android, I change some code.
|
I just landed a fix for this on iOS. Please try it out and let me know if it doesn't work for this problem. |
Summary: @public This should fix facebook#18403. When the user is inputting in Chinese/Japanese with <TextInput> in a controlled manner, the RCTBaseTextInputView will compare the JS-generated attributed string against the TextInputView attributed string and repeatedly overwrite the TextInputView one. This is because the native TextInputView will provide extra styling to show that some text is provisional. My solution is to do a plain text string comparison at this point, like how we do for dictation. Expected behavior when typing in a language that has "multistage" text input: For instance, in Chinese/Japanese it's common to type out the pronunciation for a word and then choose the appropriate word from above the keyboard. In this model, the "pronunciation" shows up in the text box first and then is replaced with the chosen word. Using the word Japan which is written 日本 but first typed as にほん. It takes 4 key-presses to get to 日本, since に, ほ, ん, are all typed and then 日本 is selected. So here is what should happen: 1. enter に, onChange fires with 'に', markedTextRange covers 'に' 2. enter ほ, onChange fires with 'にほ', markedTextRange covers 'にほ' 3. enter ん, onChange fires with 'にほん', markedTextRange covers 'にほん' 4. user selects 日本 from the menu above the keyboard (provided by the keyboard/OS), onChange fires with '日本', markedTextRange is removed previously we were overwriting the attributed text which would remove the markedTextRange, preventing the user from selecting 日本 from above the keyboard. Cheekily, I've also fixed an issue with secure text entry as it's the same type of problem. Reviewed By: PeteTheHeat Differential Revision: D9002295 fbshipit-source-id: 7304ede055f301dab9ce1ea70f65308f2a4b4a8f
Summary: @public This should fix facebook#18403. When the user is inputting in Chinese/Japanese with <TextInput> in a controlled manner, the RCTBaseTextInputView will compare the JS-generated attributed string against the TextInputView attributed string and repeatedly overwrite the TextInputView one. This is because the native TextInputView will provide extra styling to show that some text is provisional. My solution is to do a plain text string comparison at this point, like how we do for dictation. Expected behavior when typing in a language that has "multistage" text input: For instance, in Chinese/Japanese it's common to type out the pronunciation for a word and then choose the appropriate word from above the keyboard. In this model, the "pronunciation" shows up in the text box first and then is replaced with the chosen word. Using the word Japan which is written 日本 but first typed as にほん. It takes 4 key-presses to get to 日本, since に, ほ, ん, are all typed and then 日本 is selected. So here is what should happen: 1. enter に, onChange fires with 'に', markedTextRange covers 'に' 2. enter ほ, onChange fires with 'にほ', markedTextRange covers 'にほ' 3. enter ん, onChange fires with 'にほん', markedTextRange covers 'にほん' 4. user selects 日本 from the menu above the keyboard (provided by the keyboard/OS), onChange fires with '日本', markedTextRange is removed previously we were overwriting the attributed text which would remove the markedTextRange, preventing the user from selecting 日本 from above the keyboard. Cheekily, I've also fixed an issue with secure text entry as it's the same type of problem. Reviewed By: PeteTheHeat Differential Revision: D9002295 fbshipit-source-id: 7304ede055f301dab9ce1ea70f65308f2a4b4a8f
Which official release is going to have this bug fix? In RN0.56 I'm still seeing this issue |
Based on @tsangwailam 's solution, I came up with the following component. It works as a drop-in replacement (almost, except for the ref prop). It would work with external changes to the text value too.
|
Summary: @public This should fix facebook#18403. When the user is inputting in Chinese/Japanese with <TextInput> in a controlled manner, the RCTBaseTextInputView will compare the JS-generated attributed string against the TextInputView attributed string and repeatedly overwrite the TextInputView one. This is because the native TextInputView will provide extra styling to show that some text is provisional. My solution is to do a plain text string comparison at this point, like how we do for dictation. Expected behavior when typing in a language that has "multistage" text input: For instance, in Chinese/Japanese it's common to type out the pronunciation for a word and then choose the appropriate word from above the keyboard. In this model, the "pronunciation" shows up in the text box first and then is replaced with the chosen word. Using the word Japan which is written 日本 but first typed as にほん. It takes 4 key-presses to get to 日本, since に, ほ, ん, are all typed and then 日本 is selected. So here is what should happen: 1. enter に, onChange fires with 'に', markedTextRange covers 'に' 2. enter ほ, onChange fires with 'にほ', markedTextRange covers 'にほ' 3. enter ん, onChange fires with 'にほん', markedTextRange covers 'にほん' 4. user selects 日本 from the menu above the keyboard (provided by the keyboard/OS), onChange fires with '日本', markedTextRange is removed previously we were overwriting the attributed text which would remove the markedTextRange, preventing the user from selecting 日本 from above the keyboard. Cheekily, I've also fixed an issue with secure text entry as it's the same type of problem. Reviewed By: PeteTheHeat Differential Revision: D9002295 fbshipit-source-id: 7304ede055f301dab9ce1ea70f65308f2a4b4a8f
Summary: @public This should fix facebook#18403. When the user is inputting in Chinese/Japanese with <TextInput> in a controlled manner, the RCTBaseTextInputView will compare the JS-generated attributed string against the TextInputView attributed string and repeatedly overwrite the TextInputView one. This is because the native TextInputView will provide extra styling to show that some text is provisional. My solution is to do a plain text string comparison at this point, like how we do for dictation. Expected behavior when typing in a language that has "multistage" text input: For instance, in Chinese/Japanese it's common to type out the pronunciation for a word and then choose the appropriate word from above the keyboard. In this model, the "pronunciation" shows up in the text box first and then is replaced with the chosen word. Using the word Japan which is written 日本 but first typed as にほん. It takes 4 key-presses to get to 日本, since に, ほ, ん, are all typed and then 日本 is selected. So here is what should happen: 1. enter に, onChange fires with 'に', markedTextRange covers 'に' 2. enter ほ, onChange fires with 'にほ', markedTextRange covers 'にほ' 3. enter ん, onChange fires with 'にほん', markedTextRange covers 'にほん' 4. user selects 日本 from the menu above the keyboard (provided by the keyboard/OS), onChange fires with '日本', markedTextRange is removed previously we were overwriting the attributed text which would remove the markedTextRange, preventing the user from selecting 日本 from above the keyboard. Cheekily, I've also fixed an issue with secure text entry as it's the same type of problem. Reviewed By: PeteTheHeat Differential Revision: D9002295 fbshipit-source-id: 7304ede055f301dab9ce1ea70f65308f2a4b4a8f
Summary: @public This should fix facebook#18403. When the user is inputting in Chinese/Japanese with <TextInput> in a controlled manner, the RCTBaseTextInputView will compare the JS-generated attributed string against the TextInputView attributed string and repeatedly overwrite the TextInputView one. This is because the native TextInputView will provide extra styling to show that some text is provisional. My solution is to do a plain text string comparison at this point, like how we do for dictation. Expected behavior when typing in a language that has "multistage" text input: For instance, in Chinese/Japanese it's common to type out the pronunciation for a word and then choose the appropriate word from above the keyboard. In this model, the "pronunciation" shows up in the text box first and then is replaced with the chosen word. Using the word Japan which is written 日本 but first typed as にほん. It takes 4 key-presses to get to 日本, since に, ほ, ん, are all typed and then 日本 is selected. So here is what should happen: 1. enter に, onChange fires with 'に', markedTextRange covers 'に' 2. enter ほ, onChange fires with 'にほ', markedTextRange covers 'にほ' 3. enter ん, onChange fires with 'にほん', markedTextRange covers 'にほん' 4. user selects 日本 from the menu above the keyboard (provided by the keyboard/OS), onChange fires with '日本', markedTextRange is removed previously we were overwriting the attributed text which would remove the markedTextRange, preventing the user from selecting 日本 from above the keyboard. Cheekily, I've also fixed an issue with secure text entry as it's the same type of problem. Reviewed By: PeteTheHeat Differential Revision: D9002295 fbshipit-source-id: 7304ede055f301dab9ce1ea70f65308f2a4b4a8f
Summary: @public This should fix facebook#18403. When the user is inputting in Chinese/Japanese with <TextInput> in a controlled manner, the RCTBaseTextInputView will compare the JS-generated attributed string against the TextInputView attributed string and repeatedly overwrite the TextInputView one. This is because the native TextInputView will provide extra styling to show that some text is provisional. My solution is to do a plain text string comparison at this point, like how we do for dictation. Expected behavior when typing in a language that has "multistage" text input: For instance, in Chinese/Japanese it's common to type out the pronunciation for a word and then choose the appropriate word from above the keyboard. In this model, the "pronunciation" shows up in the text box first and then is replaced with the chosen word. Using the word Japan which is written 日本 but first typed as にほん. It takes 4 key-presses to get to 日本, since に, ほ, ん, are all typed and then 日本 is selected. So here is what should happen: 1. enter に, onChange fires with 'に', markedTextRange covers 'に' 2. enter ほ, onChange fires with 'にほ', markedTextRange covers 'にほ' 3. enter ん, onChange fires with 'にほん', markedTextRange covers 'にほん' 4. user selects 日本 from the menu above the keyboard (provided by the keyboard/OS), onChange fires with '日本', markedTextRange is removed previously we were overwriting the attributed text which would remove the markedTextRange, preventing the user from selecting 日本 from above the keyboard. Cheekily, I've also fixed an issue with secure text entry as it's the same type of problem. Reviewed By: PeteTheHeat Differential Revision: D9002295 fbshipit-source-id: 7304ede055f301dab9ce1ea70f65308f2a4b4a8f
Summary: @public This should fix facebook#18403. When the user is inputting in Chinese/Japanese with <TextInput> in a controlled manner, the RCTBaseTextInputView will compare the JS-generated attributed string against the TextInputView attributed string and repeatedly overwrite the TextInputView one. This is because the native TextInputView will provide extra styling to show that some text is provisional. My solution is to do a plain text string comparison at this point, like how we do for dictation. Expected behavior when typing in a language that has "multistage" text input: For instance, in Chinese/Japanese it's common to type out the pronunciation for a word and then choose the appropriate word from above the keyboard. In this model, the "pronunciation" shows up in the text box first and then is replaced with the chosen word. Using the word Japan which is written 日本 but first typed as にほん. It takes 4 key-presses to get to 日本, since に, ほ, ん, are all typed and then 日本 is selected. So here is what should happen: 1. enter に, onChange fires with 'に', markedTextRange covers 'に' 2. enter ほ, onChange fires with 'にほ', markedTextRange covers 'にほ' 3. enter ん, onChange fires with 'にほん', markedTextRange covers 'にほん' 4. user selects 日本 from the menu above the keyboard (provided by the keyboard/OS), onChange fires with '日本', markedTextRange is removed previously we were overwriting the attributed text which would remove the markedTextRange, preventing the user from selecting 日本 from above the keyboard. Cheekily, I've also fixed an issue with secure text entry as it's the same type of problem. Reviewed By: PeteTheHeat Differential Revision: D9002295 fbshipit-source-id: 7304ede055f301dab9ce1ea70f65308f2a4b4a8f
Controlled
TextInput
breaks the Chinese pinyin keyboard's autocomplete feature. A similar issue was raised a year and a half ago (#8265) and fixed by #7496. However, it appears that others are having the same problem (#12599, #18260, #18379), but re-filing the issue with the template filled out and an example to reproduce.Note that this works correctly in v0.53. This may have something to do with the big
Text
,TextInput
refactor that dropped with v0.54 (Thanks, btw, @shergin and @hovox!).I've included both a working (v0.53) and broken (v0.54) example below.
Environment
Environment:
OS: macOS High Sierra 10.13
Node: 9.3.0
Yarn: 1.3.2
npm: 5.6.0
Watchman: 4.9.0
Xcode: Xcode 9.2 Build version 9C40b
Android Studio: Not Found
Packages: (wanted => installed)
react: 16.2.0 => 16.2.0
react-native: 0.54.0 => 0.54.0
Expected Behavior
Typing on a US keyboard would bring up Chinese characters corresponding to letters typed.
Actual Behavior
Each new letter typed is considered individually, instead of along with the previous untranslated characters.
Shamelessly stealing an image from @Foru who did a nice job of showing the issue:
Steps to Reproduce
Unfortunately, expo hasn't updated to the latest version of React Native. I've prepared a small project that demonstrates the issue here. There is a working version on a branch here; same project, just using RN v0.53 instead of v0.54.
The text was updated successfully, but these errors were encountered: