[iOS][TextInput] Avoid using -[UITextView setAttributedString:] while user is typing

[mandrigin]

Motivation

iOS-specific.
For languages with complex input (such as Japanese or Chinese), a user has to type multiple characters that are then merged into a single one.
If -[UITextView setAttributedString:] is used while the user is still typing, it resets the input and characters are not being treated as typed together.

This PR avoids calling this method if possible, replacing it by just copying the attributes if the string has not been changed. That preserves the state and user can continue to type Korean or Chinese characters.

Fixes #19339

Test Plan

Essentially, the steps to reproduce are described in the issue:

1. Type some Korean characters in TextInput, such as "하늘" (buttons ㅎ,ㅏ,ㄴ,ㅡ,ㄹ).
2. Then move the cursor to the beginning of the text, type "파란" (buttons ㅍ,ㅏ,ㄹ,ㅏ,ㄴ) this time.

Behaviour before this fix (broken)
Actual text: ㅍㅏㄹㅏㄴ하늘.
Expected text: 파란하늘.
Characters aren't combined properly.

Behaviour after this fix (correct)
Actual text: 파란하늘.
Expected text: 파란하늘.
Characters are combined, the same behaviour is in vanilla iOS UITextView.

Related PRs

Release Notes

[IOS] [BUGFIX] [TextView] - Fix Korean/Chinese/Japanese input for multiline TextView on iOS.

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[RebelBIrd]

When the TextInput has props "multiline={true}", this PR is effective.Because UITextView has that Method -[UITextView setAttributedString:].
multiline={false}.still has the problem!!

[mandrigin]

@RebelBIrd yeah, this only fixes multi-line text views... I'll try to take a look at the UITextView as well to see if that is possible to fix that there...

[facebook-github-bot]

@mandrigin I tried to find reviewers for this pull request and wanted to ping them to take another look. However, based on the blame information for the files in this pull request I couldn't find any reviewers. This sometimes happens when the files in the pull request are new or don't exist on master anymore. Is this pull request still relevant? If yes could you please rebase? In case you know who has context on this code feel free to mention them in a comment (one person is fine). Thanks for reading and hope you will continue contributing to the project.

[mandrigin]

@RebelBIrd can you check if this commit: 892212b fixes your issues? If so, I can probably just close my PR.

[facebook-github-bot]

@mandrigin I tried to find reviewers for this pull request and wanted to ping them to take another look. However, based on the blame information for the files in this pull request I couldn't find any reviewers. This sometimes happens when the files in the pull request are new or don't exist on master anymore. Is this pull request still relevant? If yes could you please rebase? In case you know who has context on this code feel free to mention them in a comment (one person is fine). Thanks for reading and hope you will continue contributing to the project.

[shergin]

@rigdern Adam, what do you think?

[shergin]

For context, here is the story behind this if statement:

IIRC, originally, this if compared strings as pure strings (as it is before the change), but later we discovered that when only attributes change on JS side, the text doesn't get updated. And we changed that to comparing them as attributed string (text + attributes).

Then we discovered that sometimes/often UITextField's version of an attributed string has additional sets of attributes which made the compare operation to fail. And we changed this back.

My idea was that we have to introduce a special custom comparing function that ignores some attributes, but eventually I haven't found time for this.

This approach is very similar to what I planned to implement, but... simpler!

@mandrigin Thank you for fixing this! Спасибо!

[facebook-github-bot]

@shergin is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

[mandrigin]

@shergin Спасибо! Thanks for your explanation! Yeah, text input is very hard... I see that you are trying to avoid re-implementing all the locale support that is implemented in mobile OS-es. That is a very pragmatic and wise solution.

Simplicity was my goal, because I'm just beginning my journey into React Native world, so I don't know the internals so much. Hence, I tried to be as concise and have as small of the affected code area as possible.

My fix has one gotcha. It only fixes multiline text fields, because on iOS I see that single-line text fields are UITextFields, and not UITextViews.
I can try to investigate and make a follow-up PR to fix single line text fields. We don't have this issue ourselves, mostly because we use multi-line text fields everywhere, but I think for the completeness sake I want to fix it.

[react-native-bot]

Igor Mandrigin merged commit f77aa4e into facebook:master.

[shergin]

@mandrigin You can try to incorporate same logic somewhere here:
https://github.com/mandrigin/react-native/blob/81960c6b57673d860e7d4adeb9c5c9ca1f8486ca/Libraries/Text/TextInput/RCTBaseTextInputView.m#L113