microsoft
TextInput cursor position when manipulating text
Problem Description
When manipulating text during the onChangeText event, if the cursor is not at the end it will jump to the end. Video below is from mac but same behavior on Windows.
iOS and Android behave as expected.
Steps To Reproduce
Create the following element, add some text. Then, move cursor to the beginning of the text and add more characters. This will cause the cursor to move to the end of the text input.
<TextInput style={{flex: 1, height: 40}} value={this.state.Txt} onChangeText={(e) => {this.setState({Txt: e.toUpperCase()});}}>
Expected Results
No response
CLI version
npx react-native --version
Environment
OS: Windows 10 10.0.22000
CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
Memory: 21.85 GB / 31.73 GB
Binaries:
Node: 16.13.0 - C:\Program Files\nodejs\node.EXE
Yarn: 1.22.17 - ~\AppData\Roaming\npm\yarn.CMD
npm: 8.1.3 - C:\Program Files\nodejs\npm.CMD
Watchman: Not Found
SDKs:
Android SDK: Not Found
Windows SDK:
AllowDevelopmentWithoutDevLicense: Enabled
AllowAllTrustedApps: Enabled
Versions: 10.0.18362.0, 10.0.19041.0, 10.0.22000.0
IDEs:
Android Studio: Not Found
Visual Studio: 17.0.31912.275 (Visual Studio Community 2022)
Languages:
Java: Not Found
npmPackages:
@react-native-community/cli: Not Found
react: 17.0.2 => 17.0.2
react-native: 0.66.0 => 0.66.0
react-native-windows: 0.66.5 => 0.66.5
npmGlobalPackages:
react-native: Not Found
Target Platform Version
No response
Target Device(s)
No response
Visual Studio Version
No response
Build Configuration
No response
Snack, code example, screenshot, or link to a repository
https://user-images.githubusercontent.com/27532334/155849334-663fee2d-0b2c-4c8f-8851-d7cbf35dc61e.mov
Proposed fix: Included a prev value and cursor state to allow checking for same as prev value before checking new != old. This solves the issue of losing cursor position when you modify text in the onChangeText callback.
https://github.com/jbcullis/react-native-windows/blob/dd38db583d9fb8c7547aae5673614224b7212e60/vnext/Microsoft.ReactNative/Views/TextInputViewManager.cpp
This sounds very familiar, like something I thought was fixed. Let's check to see if the commit from the linked issue is in the version you're using, as well as if the issue I'm thinking of did indeed take a fix.
@chrisglein i didn't check .68 for a fix so it's possible. We bumped into the same issue on both Mac and windows. I put a fix in for windows on our local environment and shared a link above in case it helps.
This was the change I was thinking of: #7637 (fixing #7283). That change went into 0.64. @jbcullis Would you be willing to put up a PR with your fix above?
@chrisglein I did see that one but it didn't cover this issue.
I'll read up on how to do a PR, I'm a dinosaur still on TFS so still learning how to use GitHub.
We had a long discussion about what the correct behavior is last year. Basically, each platform at some point behaved differently. For a long time, RN Windows would set the cursor at the beginning of the text whenever programmatically updated via prop change because this is the default XAML behavior. We changed it to be a bit closer to the W3C spec, which basically states always move the cursor to the end if the text has changed. We differ from the W3C spec a bit because we keep the cursor in the same location if the text length has not changed, as this is something that appeared consistent on iOS and Android.
We're overdue for a review of what happens on iOS/Android/macOS. I believe some changes have been made on those platforms - especially on Fabric - where the behavior may now be a bit more consistent across platforms.
@rozele This issue is present on both rn-windows and rn-macos. Android and ios exhibit expected behavior.
I fixed this issue on windows .66 but never got around to figuring out how pull requests work on github but the update is here - https://github.com/jbcullis/react-native-windows/blob/dd38db583d9fb8c7547aae5673614224b7212e60/vnext/Microsoft.ReactNative/Views/TextInputViewManager.cpp
I'm planning on updating to .70 soon so will probably re-write the fix cause I noticed there has been some changes to the TextInputViewManager file.