Chinese and Japanese input don't work on iOS (blocked on RN v0.57) #2434

gnprice · 2018-04-30T18:53:02Z

The normal input methods for users to write in Chinese or in Japanese don't work in our app, on iOS.

You don't need to know any Chinese or Japanese to work on this issue; I've described how to reproduce it below. Ask me here or in chat if something is confusing.

Steps to reproduce:

In iOS settings, go to "General -> Keyboard -> Keyboards -> Add New Keyboard...". Select "Chinese (Simplified) -> Pinyin -- 10 Key".
Go to Messages, or some other app. Hit the "globe" key on your keyboard, until you get the keyboard you just added -- it has keys in the middle for "ABC", "DEF", etc., and some keys labeled in Chinese. (You can always hit the "globe" key to get back to your normal keyboard.)
Hit the keys for M G G A M, in that order. The input box should say "ni hao", which should be selected; and you should have suggestions including "你好".
- This is "hello" in Chinese. The keyboard has guessed that out of all the letter sequences you could have meant with MNO GHI GHI ABC MNO, the most likely is "ni hao"; or in Chinese characters, "你好".
- This is how this keyboard is supposed to work.
Switch to the Zulip app. Narrow to a topic somewhere, and tap the "Reply" field to start composing a message.
Hit the same five keys. The input box just says "mggam". For me, the suggestions read "is and of said has".
- It's impossible to type Chinese this way.

The keyboard "Japanese -- Kana" is similarly broken, but the repro is harder to describe starting from no knowledge of Japanese. I'll consider this issue fixed when the Chinese keyboard is working :) -- that'll probably fix the Japanese keyboard too, and I'll file a separate issue if it doesn't.

borisyankov · 2018-04-30T19:04:20Z

This is related:
facebook/react-native#18403

hjiang · 2018-07-22T13:05:10Z

I ran into this problem with the latest iOS app too. This is a video that shows the problem:
http://dropshare.47590191.mtmss.com/1Uh9o3wBA0.mov

All non-latin languages are probably broken.

hjiang · 2018-08-12T08:14:13Z

Seems the upstream issue had been closed. Is there plan to making a new release soon? The current version is unusable for CJK users.

borisyankov · 2018-08-12T10:17:02Z

The fix for the issue is in this commit:
facebook/react-native@892212b

It has not yet landed in a released version of React Native.
That should be included in 0.57 (but this is a blocker for its release facebook/react-native#20567)

The fix itself is only related to controlled inputs which we are moving away from anyway. But are blocked by another bug (facebook/react-native#18272)

Remove the iOS code which was our old 'controlled' version and keep the new Android 'uncontrolled' version. While iOS does not have the extreme performance issues the Android app had because of bugs in React Native, it is still faster to not have the component controlled - a controlled compoennt would block any time the UI thread blocks. Another big benefit is removing the need to support two versions. Making the component uncontrolled fixes zulip#2434

Fixes: zulip#2434 There is a simple hack/fix for the iOS-specific bug that was a blocker for us migrating the iOS version. If we set the text via `setNativeProps` twice in a row, it will indeed reset the contents, so the first time we use a space `' '` that looks empty but is different than the second time when we set it to an actually empty string '``'. We use `setTimeout` in order to give React Native a chance to update the native value before running the second time. For Android we don't need to call `setNativeProps` as the `TextInputReset.resetKeyboardInput` call does that. Also compared to the previous version we don't need to check if `TextInputReset` is defined as it isn't only for iOS and we `if` for that.

gnprice · 2018-08-16T08:08:11Z

For everyone's enjoyment/education: that upstream commit facebook/react-native@892212bad has a very nice explanation of the diagnosis and the fix.

Remove the iOS code which was our old 'controlled' version and keep the new Android 'uncontrolled' version. While iOS does not have the extreme performance issues the Android app had because of bugs in React Native, it is still faster to not have the component controlled - a controlled compoennt would block any time the UI thread blocks. Another big benefit is removing the need to support two versions. Making the component uncontrolled fixes zulip#2434

Fixes: zulip#2434 There is a simple hack/fix for the iOS-specific bug that was a blocker for us migrating the iOS version. If we set the text via `setNativeProps` twice in a row, it will indeed reset the contents, so the first time we use a space `' '` that looks empty but is different than the second time when we set it to an actually empty string '``'. We use `setTimeout` in order to give React Native a chance to update the native value before running the second time. For Android we don't need to call `setNativeProps` as the `TextInputReset.resetKeyboardInput` call does that. Also compared to the previous version we don't need to check if `TextInputReset` is defined as it isn't only for iOS and we `if` for that.

Remove the iOS code which was our old 'controlled' version and keep the new Android 'uncontrolled' version. While iOS does not have the extreme performance issues the Android app had because of bugs in React Native, it is still faster to not have the component controlled - a controlled compoennt would block any time the UI thread blocks. Another big benefit is removing the need to support two versions. Making the component uncontrolled fixes zulip#2434

Fixes: zulip#2434 There is a simple hack/fix for the iOS-specific bug that was a blocker for us migrating the iOS version. If we set the text via `setNativeProps` twice in a row, it will indeed reset the contents, so the first time we use a space `' '` that looks empty but is different than the second time when we set it to an actually empty string '``'. We use `setTimeout` in order to give React Native a chance to update the native value before running the second time. For Android we don't need to call `setNativeProps` as the `TextInputReset.resetKeyboardInput` call does that. Also compared to the previous version we don't need to check if `TextInputReset` is defined as it isn't only for iOS and we `if` for that.

Fixes zulip#2434 Fixes zulip#3053 Remove the iOS code which was our old 'controlled' version and keep the new Android 'uncontrolled' version. While iOS does not have the extreme performance issues the Android app had because of bugs in React Native, it is still faster to not have the component controlled - a controlled compoennt would block any time the UI thread blocks. Another big benefit is removing the need to support two versions.

Resolves zulip#3017, Fixes zulip#2434, Fixes zulip#3053 Remove the iOS code which was our old 'controlled' version and keep the new Android 'uncontrolled' version. While iOS does not have the extreme performance issues the Android app had because of bugs in React Native, it is still faster to not have the component controlled - a controlled compoennt would block any time the UI thread blocks. Another big benefit is removing the need to support two versions.

Closes zulip#3017. Fixes zulip#2434. Fixes zulip#3053. Remove the iOS code which was our old 'controlled' version and keep the new Android 'uncontrolled' version. While iOS does not have the extreme performance issues the Android app had because of bugs in React Native, it is still faster to not have the component controlled - a controlled compoennt would block any time the UI thread blocks. Another big benefit is removing the need to support two versions.

gnprice added the bug label Apr 30, 2018

gnprice added the a-iOS label May 24, 2018

borisyankov mentioned this issue Jun 6, 2018

Compose box uncontrolled #2595

Closed

gnprice added the upstream: RN Issues related to an issue in React Native label Jun 14, 2018

gnprice mentioned this issue Aug 16, 2018

Turn iOS compose box uncontrolled; dedupe with Android #2886

Closed

gnprice changed the title ~~Chinese and Japanese input don't work on iOS~~ Chinese and Japanese input don't work on iOS (blocked on RN v0.57) Sep 24, 2018

gnprice mentioned this issue Oct 11, 2018

I can not input chinese on ios #3033

Closed

x007007007 mentioned this issue Oct 12, 2018

ios chinese input bug fix #3036

Closed

gnprice added the a-compose/send Compose box, autocomplete, camera/upload, outbox, sending label Oct 18, 2018

gnprice mentioned this issue Oct 18, 2018

Autocorrect on iOS Compose Input #3053

Closed

borisyankov mentioned this issue Nov 1, 2018

Unify the two platform's ComposeBox code #3095

Merged

gnprice assigned borisyankov Nov 1, 2018

gnprice added the review label Nov 1, 2018

gnprice closed this as completed in #3095 Nov 1, 2018

gnprice removed the review label Nov 1, 2018

gnprice added the a-i18n Translation, localization, internationalization label Apr 24, 2020

gnprice mentioned this issue Apr 24, 2020

Cannot select chatacter when typing #2416

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Chinese and Japanese input don't work on iOS (blocked on RN v0.57) #2434

Chinese and Japanese input don't work on iOS (blocked on RN v0.57) #2434

gnprice commented Apr 30, 2018 •

edited

Loading

borisyankov commented Apr 30, 2018

hjiang commented Jul 22, 2018

hjiang commented Aug 12, 2018

borisyankov commented Aug 12, 2018

gnprice commented Aug 16, 2018

Chinese and Japanese input don't work on iOS (blocked on RN v0.57) #2434

Chinese and Japanese input don't work on iOS (blocked on RN v0.57) #2434

Comments

gnprice commented Apr 30, 2018 • edited Loading

borisyankov commented Apr 30, 2018

hjiang commented Jul 22, 2018

hjiang commented Aug 12, 2018

borisyankov commented Aug 12, 2018

gnprice commented Aug 16, 2018

gnprice commented Apr 30, 2018 •

edited

Loading