feat(keyboard): after sending from a chat composer, no way to return the keyboard to its default state (layout and pending autocorrection)
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
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:
- 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 togglinginputmode. Taking focus away does reset the layout, but it hides the keyboard and fireskeyboardWillHide/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
tehso the keyboard shows the correctionthe, tap send. The text sent isteh.
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
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ionic-team/capacitor-plugins
-
triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 80/100
ionic-team/capacitor-plugins#2627 ·
I maintainer di solito rispondono entro 1 giorno
-
triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
ionic-team/capacitor-plugins#2616 ·
I maintainer di solito rispondono entro 1 giorno
-
[@capacitor/app] iOS: 'Expression implicitly coerced from String? to Any' warning in getAppLanguageApertatriage
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
ionic-team/capacitor-plugins#2604 ·
I maintainer di solito rispondono entro 1 giorno
-
bug(action-sheet, camera): on iPhone with Liquid Glass, action sheets show as a popover without the Cancel actionForse già presa @arblitroshani l’ha presa oggi. Apertaplatform: ios
Difficoltà 3/5 1-2 giorni Idoneità per principianti 20/100
ionic-team/capacitor-plugins#2630 ·
I maintainer di solito rispondono entro 1 giorno
-
bug(status-bar): iOS WebView moves under the status bar after a full-screen modal is dismissedForse già presa @kidzki l’ha presa oggi. Apertaplatform: ios
Difficoltà 3/5 1-2 giorni Idoneità per principianti 25/100
ionic-team/capacitor-plugins#2625 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di ionic-team/capacitor-plugins
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 63/100
wpilibsuite/SystemcoreTesting#446 ·
I maintainer di solito rispondono entro 1 giorno
-
frontend quality-assurance
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
Paul-Austin-Oswego-CSC480-HCI521/gift-app#212 ·
I maintainer di solito rispondono entro 1 giorno
-
Mend: dependency security vulnerability
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno
-
Docs: AGENTS.md agent/ module-map bullet missing AgentWriteRules — the deny-by-default write gateApertadocumentation hermes-queue
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 84/100
chrisalunlloyd2-sudo/mindpalace#334 ·
I maintainer di solito rispondono entro 1 giorno
-
needs-area-label
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 2 giorni