feat(keyboard): after sending from a chat composer, no way to return the keyboard to its default state (layout and pending autocorrection)

Aperta
#2,619 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
24/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
android, ios, java, javascript, swift
Ambito
mobile, mobile-dev

Direzione di ricerca

Start by reading the keyboard plugin API and its native iOS and Android implementations; the issue names no specific files or tests. Investigate whether either platform exposes a way to apply pending autocorrection and restore the letters layout while keeping focus and the keyboard open. Done means both behaviors work without keyboard hide/show events on iOS and Android; the issue provides reproduction steps for a focused textarea and send button.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

platform: android platform: ios

Feature request

Plugin(s)

@capacitor/keyboard 8.0.6

Platform(s)

iOS, Android

Current problem

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:

  1. 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.
  2. 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.

Lingua principale
Java
Stelle
688
Fork
691
Merge medio
1g 15h
PR unite (30g)
3

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ionic-team/capacitor-plugins

Tutte le issue di ionic-team/capacitor-plugins

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.