Skip to content
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

[ios] TextInput onSubmitEditing not working on 0.72.x, but worked on 0.70 & 0.62 #40761

Open
aweffr opened this issue Oct 10, 2023 · 5 comments
Labels
Component: TextInput Related to the TextInput component. Needs: Repro This issue could be improved with a clear list of steps to reproduce the issue. Needs: Triage 🔍 Platform: iOS iOS applications.

Comments

@aweffr
Copy link

aweffr commented Oct 10, 2023

Description

We have a chat app that heavily use <TextInput />,

on iOS, it was set as multiline={true}, blurOnSubmit={false} as intended, because we want our user to keep keyboard up and can edit multiple lines, hit 'Send' button on keyboard and just send out the content.

Our app has been used in production for some years, multiline={true} + blurOnSubmit={false} + onSubmitEditing={...} always working, until we test it on 0.72.x.

For us, 0.72 is a awesome release becaucse the feaute of maintainVisiblePositon feature on android, and some free performace increasement based on our measurement. We hope bring back the onSubmitEditing original behavior as how it works on 0.70 & 0.62.

React Native Version

0.72.5

Output of npx react-native info

info Fetching system and libraries information...
System:
OS: macOS 13.4
CPU: (12) arm64 Apple M2 Max
Memory: 735.38 MB / 32.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node:
version: 16.19.0
path: ~/.nvm/versions/node/v16.19.0/bin/node
Yarn:
version: 1.22.19
path: ~/.nvm/versions/node/v16.19.0/bin/yarn
npm:
version: 8.19.3
path: ~/.nvm/versions/node/v16.19.0/bin/npm
Watchman:
version: 2023.08.14.00
path: /opt/homebrew/bin/watchman
Managers:
CocoaPods:
version: 1.12.1
path: /Users/aweffr/.rbenv/shims/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 22.2
- iOS 16.2
- macOS 13.1
- tvOS 16.1
- watchOS 9.1
Android SDK: Not Found
IDEs:
Android Studio: 2022.1 AI-221.6008.13.2211.9619390
Xcode:
version: 14.2/14C18
path: /usr/bin/xcodebuild
Languages:
Java:
version: 11.0.11
path: /usr/bin/javac
Ruby:
version: 2.7.7
path: /Users/aweffr/.rbenv/shims/ruby
npmPackages:
"@react-native-community/cli": Not Found
react:
installed: 18.2.0
wanted: 18.2.0
react-native:
installed: 0.72.5
wanted: 0.72.5
react-native-macos: Not Found
npmGlobalPackages:
"react-native": Not Found
Android:
hermesEnabled: true
newArchEnabled: false
iOS:
hermesEnabled: false
newArchEnabled: false

Steps to reproduce

Snack, screenshot, or link to a repository

  1. How this feature worked on 0.70.12
Screen.Recording.-.onSubmitEditing.working.on.0.70.12.mp4
  1. How this feature not working on 0.72.5
Screen.Recording.-.onSubmitEditing.not.working.on.0.72.5.mp4
@github-actions github-actions bot added Component: TextInput Related to the TextInput component. Platform: iOS iOS applications. Needs: Repro This issue could be improved with a clear list of steps to reproduce the issue. labels Oct 10, 2023
@github-actions
Copy link

⚠️ Missing Reproducible Example
ℹ️ We could not detect a reproducible example in your issue report. Please provide either:
  • If your bug is UI related: a Snack
  • If your bug is build/update related: use our Reproducer Template. A reproducer needs to be in a GitHub repository under your username.

@uesleisuptitz
Copy link

Use onBlur method instead

@mhoran
Copy link

mhoran commented Feb 23, 2024

Here is a Snack that reproduces the bug: https://snack.expo.dev/@mhoran/awkward-red-waffles (run on iOS).

Using the on screen keyboard, enter some text in the text area. Then click send. Note that a newline is added to the text input, and to the display area just above.

This worked as expected in previous react-native versions, but is not working in recent versions. The exact breaking release is unknown, but the Snack does not work as expected all the way back to Expo v48 (react-native 0.71.3).

Changing multiline={true} to multiline={false} shows the previous behavior (and works as expected). But of course that means multiline text cannot be pasted into the text input.

@uesleisuptitz onBlur is not an acceptable substitute for onSubmitEditing when blurOnSubmit={false}. This may be used by apps that wish not to dismiss the keyboard when the text input is submitted (e.g. chat apps). onSubmitEditing also fires as expected when blurOnSubmit={true}.

I have not been able to use multiline={true} in my app for some time due to #27019, but this is an additional blocker.

@Ashoat
Copy link
Contributor

Ashoat commented Jun 2, 2024

Hey @mhoran, just stumbling on this issue. This doesn't really address the legitimate bug you're reporting here, but figured I'd mention some related stuff.

React Native's TextInput is broken for a chat input bar use case in other ways as well, and at my current company we found it necessary to render a new TextInput for each text message the user sends. Some context on Twitter.

In order to make this work, we blur one TextInput and immediately focus a new one, and it's not noticeable on either iOS or Android. This is actually the only way to address several other deficiencies of the TextInput for chat input bar, so blurOnSubmit is probably not the best thing to be used here anyways.

@mhoran
Copy link

mhoran commented Oct 27, 2024

After upgrading to React Native 0.76.0 I noticed a deprecation warning regarding blurOnSubmit. it seems this has been replaced with an undocumented (?!) field submitBehavior. Setting submitBehavior="submit" on a multiline TextInput works as expected. See updated Snack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: TextInput Related to the TextInput component. Needs: Repro This issue could be improved with a clear list of steps to reproduce the issue. Needs: Triage 🔍 Platform: iOS iOS applications.
Projects
None yet
Development

No branches or pull requests

4 participants