Please sign in to comment.
Fix controlled <TextInput> on iOS when inputting in Chinese/Japanese
Summary: @public This should fix #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
- Loading branch information...
Showing with 62 additions and 16 deletions.