You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(keyboard): after sending from a chat composer, no way to return the keyboard to its default state (layout and pending autocorrection) #2619
In a chat app, the user types into a composer and taps a send button. The app reads the text, clears the field, and the field keeps focus so the next message can be typed right away. The keyboard does not get any signal that a message was sent, which causes two problems:
The layout stays where it was. If the user switched to the emoji, numbers or symbols layout for that message, the next message starts there instead of on letters.
A pending autocorrection is lost. If the keyboard is showing a correction for the last word (for example teh → the), tapping send gets the literal text from the field. The correction is applied only by a key the keyboard itself handles, like space, and a send button in the page is not one of those keys.
Native messaging apps (WhatsApp, Messages, Telegram) handle both. Sending applies the pending correction to the last word, and the keyboard goes back to letters while it stays open.
A Capacitor app cannot do either:
The plugin's API (show, hide, setAccessoryBarVisible, setScroll, setStyle, setResizeMode, getResizeMode, listeners) has nothing that affects the keyboard's current layout or its pending correction.
From the web side, none of these apply the pending correction on iOS: blur() + focus() (sync and deferred), moving the caret, execCommand('insertText'), or toggling inputmode. Taking focus away does reset the layout, but it hides the keyboard and fires keyboardWillHide/keyboardWillShow, so the page jumps down and up on every send.
From an app-target native plugin we found no public call that does either one with the keyboard kept open.
Preferred solution
After a message is sent, the app can bring the open keyboard back to its default state: the pending correction is applied to the field's text, and the layout returns to letters. The keyboard stays open, the field keeps focus, and no hide/show events fire.
Alternatives
None found. Today the app sends the uncorrected text and leaves the keyboard on whatever layout the user last picked.
Additional context
Reproduce on iOS (iPhone 15 Pro, iOS 26) in a Capacitor app with a focused <textarea> and a send button that reads and clears it while keeping focus:
Switch the keyboard to emoji, type, tap send. The keyboard stays on emoji.
Type teh so the keyboard shows the correction the, tap send. The text sent is teh.
On Android (Samsung Galaxy A06, Samsung Keyboard) the layout stays the same way after a send.
Activity