-
-
Notifications
You must be signed in to change notification settings - Fork 655
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Autocorrect on iOS Compose Input #3053
Comments
Thanks for the report and the clear screencaps! I suspect this is the same underlying issue as #2434 , though I don't understand this subsystem well enough to be confident that's the case. That issue should be fixed in RN v0.57. Would you try the tip of #2789 (which upgrades us to that version) and see if this issue still reproduces there? (And if it does, also try reproducing #2434 to confirm I haven't misunderstood something there?) If we're lucky, that does fix it. |
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.
I added the |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
And master is now on RN v0.57, after merging #2789! Our belief above was that that would fix this issue. (Even without any further changes.) @armaanahluwalia or @borisyankov , would you give it a quick check to confirm whether it still reproduces? |
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.
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.
Closes zulip#3017. 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 component would block any time the UI thread blocks. Another big benefit is removing the need to support two versions.
Well anyway, #3095 now merged too to fix the issue. Thanks again @armaanahluwalia for reporting this! |
Autocorrect does not behave as expected on the iOS compose message input. Basically this is very easy to reproduce. See the video for a comparison of behavior on iMessage and Zulip.
Ideally Zulip would be able to autocorrect in the middle of a sentence like iMessage does.
https://streamable.com/8w70j
https://streamable.com/glcz7
If you notice at the end of the second video the cursor jumps to the end. That happened when I tried to type a character it wasn't me moving the cursor manually. It seems to lose its place ( this is not as easily repro-able as the autocorrect problem and may be related to #3052 )
Seen on on iOS 18.0.99
The text was updated successfully, but these errors were encountered: