Summary:
A very common pattern I've seen in RN codebase:
- (instancetype) init {
[[NSNotificationCenter defaultCenter] addObserver:self ...]
}
- (void) dealloc {
[[NSNotificationCenter defaultCenter] removeObserver:self ...]
}
From Apple:
https://developer.apple.com/documentation/foundation/nsnotificationcenter/1413994-removeobserver?language=objc
> If your app targets iOS 9.0 and later or macOS 10.11 and later, you don't need to unregister an observer in its dealloc method.
RN targets iOS9+
Changelog: [Internal][Cleanup] Remove unneeded NSNotification center removeObserver
Reviewed By: shergin
Differential Revision: D18264235
fbshipit-source-id: 684e5f5555cec96b055b13cd83daaeb393f4fac9
Summary:
This diff changes how we apply default text attributes to backed text input.
The original change in https://github.com/facebook/react-native/pull/23585 that introduced the `reactTextAttributes` field in for RCTBackedTextInputViewProtocol was great! Thank you Wu zhongwuzw !
However, there is one detail that needs to be changed.
RCTBackedTextInputViewProtocol is designed to only abstract complexity of iOS text input components (UITextView and UITextField); it intentionally does not have any React-specific fields or types. Adding a field `RCTTextAttributes *reactTextAttributes;` violates this principle and make it hard to reuse this functionality in the new Fabric-powered TextInput.
This diff changes the type of this prop from `RCTTextAttributes` to `NSDictionary<NSAttributedStringKey,id> *` (exact same type that UITextView and UITextField use).
Reviewed By: cpojer
Differential Revision: D17408501
fbshipit-source-id: 65f2bba119ccc30f22e87c28d0f8ea6f731cd365
Summary:
The new podspec includes all .h and .m files, `RCTInputAccessoryViewContent` was missing a tvOS guard.
## Changelog
[iOS] [Fixed] - Restore RCTText tvOS pod compatibility
Pull Request resolved: https://github.com/facebook/react-native/pull/26332
Test Plan: Build RCTText for tvOS
Differential Revision: D17258958
Pulled By: cpojer
fbshipit-source-id: 5e7408680133aa3ec111552d1413a928193945a7
Summary:
Move RCTAccessibilityManager to CoreModules (since that's the only dir that supports TM).
Fixup some variable names to match spec.
Reviewed By: RSNara
Differential Revision: D16861739
fbshipit-source-id: a0a53b221dcc172979d1f2c83851ab92e23f2333
Summary:
This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349.
It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`.
The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` .
There are still a few breaking changes which I hope will be acceptable:
- `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path.
- ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967.
- ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled.
Still to do:
- ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302.
- I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? �
## Changelog
[iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks.
Pull Request resolved: https://github.com/facebook/react-native/pull/25619
Test Plan:
### FB
```
buck build catalyst
```
### Sample Project
Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed.
You can see that it works with these steps:
1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git`
2. `git checkout fix-frameworks-subspecs`
3. `cd ios && pod install`
4. `cd .. && react-native run-ios`
The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again.
### RNTesterPods
`RNTesterPodsPods` can now work with or without `use_frameworks!`.
1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.
Reviewed By: PeteTheHeat
Differential Revision: D16465247
Pulled By: PeteTheHeat
fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
Summary:
On `textContentType` `newPassword` on ios, there is another property called `passwordRules` on ios 12 that can give hints to the os to generate a password with specific requirements like [here](https://developer.apple.com/password-rules/).
This is useful for apps that have a "register" screen with `emailAddress`/`username` and a `newPassword` fields, to let ios make a password that will satisfy the requirements and not one that might be not accepted after the user presses "register".
## Changelog
[iOS] [Added] - PasswordRules for new password textContentType input fields
Pull Request resolved: https://github.com/facebook/react-native/pull/25407
Test Plan: This is a bit harder, but to test you need to make an app that has associated domains with an apple-app-site-association file on that domain, enable iCloud Keychain on the test device, and then iOS will suggest a password, otherwise you will just get a warning on Xcode saying "Couldn't suggest password because of: blabla".
Differential Revision: D16028684
Pulled By: cpojer
fbshipit-source-id: d22426e07f1db45d1f79f5dad81f1465a9701f0b
Summary:
Issue reported by Titozzz , `TextInput` would shrink when we have attributes like `lineHeight`.
Demonstration can see GIF like below:
https://giphy.com/gifs/KGNs1qIMHF3DIk1EPK
I think the reason is we apply an empty attributed string to `UITextField`, now if the length is 0, we just nil the `attributedText` instead.
## Changelog
[iOS] [Fixed] - Don't apply empty attributed string for TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/25143
Differential Revision: D15661751
Pulled By: sammy-SC
fbshipit-source-id: 9770484a1b68a6409e63ea25ac9a6fd0d3589b14
Summary:
Original commit changeset: f149721d6b4d (D15238379)
This commit was causing the following crash: Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'An instance 0x7fb3453eda00 of class RCTUITextField was deallocated while key value observers were still registered with it.
FB: See also P64445585 T44107377 T44169319
Reviewed By: mmmulani
Differential Revision: D15323255
fbshipit-source-id: 037c34ae387d912c5ea03eaa364b8c60367df357
Summary:
UITextView is accessible by default (some nested views are) and disabling that is not supported.
The problem happened because JS side sets `isAccessible` flag for UITextView and UITextField to `true` (with good intent!), which actually disables (surprise!) bult-in accessibility of TextInput on iOS.
On iOS accessible elements cannot be nested, so enabling accessibily for some container view (even in a case where this is view is a public API of TextInput on iOS) shadows some features implemented inside the component.
(Disabling accessibility of TextInput via `accessible=false` was never supported.)
Reviewed By: JoshuaGross
Differential Revision: D15280667
fbshipit-source-id: 72509b40383db6ef66c4263bd920f5ee56a42fc1
Summary:
`UITextField` don't have delegate to observe the selection changes of users(multiline text input `UITextView` have it), so we can add a KVO to observe selection changes.
cpojer shergin
[iOS] [Fixed] - Fixes selection of single line text input
Pull Request resolved: https://github.com/facebook/react-native/pull/24714
Differential Revision: D15238379
Pulled By: cpojer
fbshipit-source-id: f149721d6b4df28e90f5a9405c74e01fde7c7d10
Summary:
Bug comes from #23545, if `allowedLength < 0`, it would crash if `text.length > 1`.
cc. cpojer
[iOS] [Fixed] - Fixed crash when textinput's default value exceeds maxLength
Pull Request resolved: https://github.com/facebook/react-native/pull/24084
Differential Revision: D14562719
Pulled By: cpojer
fbshipit-source-id: 87ed930e35b8fa889d8b04829795fa46b7787b07
Summary:
Keep placeholder paragraph style same with text input.
[iOS] [Fixed] - Keep placeholder paragraph style same with single line text input
Pull Request resolved: https://github.com/facebook/react-native/pull/23765
Differential Revision: D14321255
Pulled By: cpojer
fbshipit-source-id: 2b8cbb7f2c7ceb40a9a2b142065dd6f5eb3d62eb
Summary:
After #23738 , we can add more text attributes to placeholder, so now, let's update the calculation of placeholder size based on placeholder attributes.
[iOS] [Fixed] - Fixed singleline text input placeholder size
Pull Request resolved: https://github.com/facebook/react-native/pull/23745
Differential Revision: D14320630
Pulled By: cpojer
fbshipit-source-id: 2d9e8b59ba70228202add762cfc9c6cbc77e5e95
Summary:
After some refactor of text input attributes, we can now add style attributes the same as text input's attributes, from https://github.com/facebook/react-native/issues/19002#issuecomment-467171589, user wants placeholder to support line-height , I think we can add it now for multiline text input.
[iOS] [Added] - Added lineHeight support of placeholder for multiline text input
Pull Request resolved: https://github.com/facebook/react-native/pull/23760
Differential Revision: D14320600
Pulled By: cpojer
fbshipit-source-id: ededeaa11560af089ca15ffc188e2e70db2ad7d4
Summary:
After #23738 , we can add more text attributes to placeholder, so now, let's update the calculation of placeholder size based on placeholder attributes.
[iOS] [Fixed] - Fixed multiline text input placeholder size
Pull Request resolved: https://github.com/facebook/react-native/pull/23742
Differential Revision: D14320489
Pulled By: cpojer
fbshipit-source-id: 6b0f07fe7406d5c99c7280d584f8b8e51fc84c00
Summary:
We need to keep placeholder attributes sync with text input's text attributes, like `font`,`kern` ....., to keep style the same.
Also fixes#19002 .
[iOS] [Fixed] - Keep placeholder attributes sync with text input text's attributes
Pull Request resolved: https://github.com/facebook/react-native/pull/23738
Differential Revision: D14298482
Pulled By: cpojer
fbshipit-source-id: 3555091bf3bc01e4b026d5a4cdbe93b4122106e8
Summary:
We have the wrong calculation of placeholder size currently, leads `contentSize` or some things inaccuracy.
[iOS] [Fixed] - Fixed wrong placeholder size calculation in multiline text input mode
Pull Request resolved: https://github.com/facebook/react-native/pull/23682
Differential Revision: D14255932
Pulled By: cpojer
fbshipit-source-id: a1f40e90fc2c848579694965da8316fae9e5c4c5
Summary:
Currently, we pick the max size of text view's contentSize and placeholder's size, actually, if placeholder is be hidden, we should only return text view's contentSize.
[iOS] [Fixed] - Fixed wrong contentSize calculation when placeholder is hidden in multiline text input
Pull Request resolved: https://github.com/facebook/react-native/pull/23683
Differential Revision: D14255915
Pulled By: cpojer
fbshipit-source-id: 198faa7e1c5657371eb920973345194aedf72e41
Summary:
Placeholder's font not consistent with text's font, it leads to cursor dislocation. We need to keep consistent between placeholder and text.
[iOS] [Fixed] - Fixed placeholder font not consistent with text's font when in multiline mode
Pull Request resolved: https://github.com/facebook/react-native/pull/23654
Differential Revision: D14226174
Pulled By: hramos
fbshipit-source-id: 7cfb3b73d8799d22d5cbbfe557df8de3f5fcf034
Summary:
We already only support `iOS9+`, so we can remove all compatible codes now.
[iOS] [Fixed] - Remove compatible system code for iOS8 and before
Pull Request resolved: https://github.com/facebook/react-native/pull/23656
Differential Revision: D14224986
Pulled By: hramos
fbshipit-source-id: cac9ffe6788dd3eaf4f4f5f2b219f325ba78e85f
Summary:
Currently, if we has `defaultValue`, textAttributes like `letterSpacing` can works, but if textinput has not default text, when we typing the text, some attributes not applied.
[iOS] [Fixed] - Fix textAttributes not applied when typing text
Pull Request resolved: https://github.com/facebook/react-native/pull/23585
Differential Revision: D14206568
Pulled By: cpojer
fbshipit-source-id: 7db276d811684bf6e01f8d30287cca80095db87c
Summary:
This PR (https://github.com/facebook/react-native/pull/22546) broke single line text inputs. After inputting some text and tapping away, the text input reverts back to default text.
Revert solved the issue.
Reviewed By: cpojer
Differential Revision: D14185897
fbshipit-source-id: cc7f0f2ebfb0494062afbc628c4fe27ad27fb1c6
Summary:
This is a fix for #5859, based on the feedback in #18587. Instead of using `didSetProps` it uses a setter. I will also note that setting to `nil` no longer works (crashes) so setting it to a blank string then back to the original works fine.
[iOS] [Fixed] - Toggling secureTextEntry correctly places cursor.
Pull Request resolved: https://github.com/facebook/react-native/pull/23524
Differential Revision: D14143028
Pulled By: cpojer
fbshipit-source-id: 5f3203d56b1329eb7359465f8ab50eb4f4fa5507
Summary:
Throw error warning when build Text module, we can add tvOS available check to remove error.
[iOS] [Fixed] - Fix build error warning of Text module
Pull Request resolved: https://github.com/facebook/react-native/pull/23586
Differential Revision: D14181198
Pulled By: cpojer
fbshipit-source-id: 6a62c831ba119ddcbc6effa0b24f22bd4588b982
Summary:
This is an updated version of #22579 which uses compile conditionals to prevent `use of undeclared identifier` errors when compiling on older versions of Xcode.
--------
Currently the only `textContentType` values that work are: `username`, `password`, `location`, `name` and `nickname`. This is due to the strings provided by React Native not matching up with the underlying string constants used in iOS (with the exception of the aforementioned types). Issue #22578 has more detail examples/explanation.
Pull Request resolved: https://github.com/facebook/react-native/pull/22611
Differential Revision: D13460949
Pulled By: cpojer
fbshipit-source-id: e6d1108422b850ebc3aea05693ed05118b77b5de
Summary:
If we change the text attributes dynamically, for example, change the textColor, it not works in iOS, Android works fine.
[iOS] [fixed] - Fixed textInput appearance not update when text attributes changed
Pull Request resolved: https://github.com/facebook/react-native/pull/23533
Differential Revision: D14146700
Pulled By: cpojer
fbshipit-source-id: 4a7c84d6e7f818acb712242bea6484b177a775c6
Summary:
I found the TextInput can't control input length when default value's length > maxLength.
for example：
1.Set the value in special cases
```
<TextInput value={'12345678'} maxLength={6}/>
```
2.Quickly press the keyboard with multiple fingers
```
// RCTBaseTextInputView.m
……
if (_maxLength) {
NSUInteger allowedLength = _maxLength.integerValue - backedTextInputView.attributedText.string.length + range.length;
if (text.length > allowedLength) {
……
```
when value's length > maxLength,the allowedLength not a negative number.it was transformed into a big number,because it is type NSUInteger.so the `text.length > allowedLength` always false.
[iOS][Fixed] - fix the TextInput can't control input length when value's length > maxLength
Pull Request resolved: https://github.com/facebook/react-native/pull/23545
Differential Revision: D14146581
Pulled By: cpojer
fbshipit-source-id: f53b1312ae55fad9fc10430ab94784c1a9ad4723
Summary:
Fixes#21243.
Fixes#20908.
Credit goes to superandrew213 who provided the patch based on 0.56; this commit merges and resolved the conflict introduced in 0.57.
Pull Request resolved: https://github.com/facebook/react-native/pull/21951
Differential Revision: D13980799
Pulled By: cpojer
fbshipit-source-id: 6b9f1a1ae54ad9dba043005d683d6a221472c729
Summary:
Follow-up to https://github.com/facebook/react-native/pull/19809
This fix generalizes the `setAttributedString:` fix to single-line text fields.
Fixes#19339
_Pull requests that expand test coverage are more likely to get reviewed. Add a test case whenever possible!_
Pull Request resolved: https://github.com/facebook/react-native/pull/22546
Differential Revision: D13948951
Pulled By: shergin
fbshipit-source-id: 67992c02b32f33f6d61fac4554e4f46b973262c1
Summary:
Fixes#22578
Currently the only `textContentType` values that work are: `username`, `password`, `location`, `name` and `nickname`. This is due to the strings provided by React Native not matching up with the underlying string constants used in iOS (with the exception of the aforementioned types). Issue #22578 has more detail examples/explanation.
Pull Request resolved: https://github.com/facebook/react-native/pull/22579
Differential Revision: D13402177
Pulled By: shergin
fbshipit-source-id: 55f4a2029cd3ea1fb4834e9f56d2df5a05b31b4e
Summary:
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
<!--
Required: Write your motivation here.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
-->
<!--
Required: Write your test plan here. If you changed any code, please provide us with
clear instructions on how you verified your changes work. Bonus points for screenshots and videos!
-->
Essentially, the steps to reproduce are described in [the issue](https://github.com/facebook/react-native/issues/19339):
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`.
<!--
Does this PR require a documentation change?
Create a PR at https://github.com/facebook/react-native-website and add a link to it here.
-->
<!--
Required.
Help reviewers and the release process by writing your own release notes. See below for an example.
-->
[IOS] [BUGFIX] [TextView] - Fix Korean/Chinese/Japanese input for multiline TextView on iOS.
<!--
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAL ] [ BUGFIX ] [ {Component} ]
[ INTERNAL ] [ ENHANCEMENT ] [ {Filename} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/19809
Differential Revision: D13326614
Pulled By: shergin
fbshipit-source-id: 6a5cab3f7290f0f623a6f4c29353a573eb321b0b
Summary:
1. The user inserts a character ('0') at index 0. Because the range matches 0, 0, predictedText is set to that character that was inserted.
2. In textInputDidChange, it discovers a mismatch between the rendered text ('1234') and predicted text ('0')
3. This triggers textInputShouldChangeTextInRange to be called again with the 'new' text that it thinks was just added ('1234')
4. It goes to insert this text, but runs into the maxLength limit, so it gets truncated and then inserted.
(I'm not totally sure why only happens if maxLength is set - I need to look into that.)
One fix for this is to just get rid of the range check, but that'll regress #18374. I decided to just check and see if the rendered text is empty instead of checking the range where text could be inserted, since that seems like it should properly handle both cases.
Reviewed By: shergin
Differential Revision: D10392176
fbshipit-source-id: 84fb3b6cac9b0aa25b3c1a127d43f9cdc5a1c6a8
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
On iOS, it is not possible to select a range of text using a `Text` component (see #13938). Because of how the `Text` component is implemented on iOS, this will not work without a complete re-write. On Android however, this is not an issue.
As the `TextInput` component has evolved, it can more or less be used as a drop-in replacement on iOS by setting `multiline={true}` and `editable={false}`. Except for one detail: the text input field has scrolling activated and it's not possible to turn off. (See #1391 and #15962).
This pull request addresses that issue, simply by exposing the `scrollEnabled` property:
```
<TextInput
multiline
editable={false}
scrollEnabled={false}
/>
```
1. Create a multiline `TextInput` component, with the attributes presented above.
2. Run on iOS
3. The `TextInput` field should not be able to scroll
facebook/react-native-website#367
[IOS] [FEATURE] [TextInput] - Made it possible to turn off scrolling on a multiline TextInput component
Pull Request resolved: https://github.com/facebook/react-native/pull/19330
Differential Revision: D9235061
Pulled By: hramos
fbshipit-source-id: 99d278004fc236b47dde7e61d74c71e8a3b9d170
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
Peter Argany
Andres Suarez
Valentin Shergin
Benoit Dion
James Treanor
Min ho Kim
Pavlos Vinieratos
Christoph Nakazawa
zhongwuzw
Joshua Gross
Xiuli Shen
Estevão Lucas
Eric Lewis
Levi Buzolic
jsfu
dchersey
Igor Mandrigin
Ben Holcomb
Igor Mandrigin
Emily Janzer
Janic Duplessis
Héctor Ramos
magicien
Johannes Baldursson
Mehdi Mulani
