Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

bug(keyboard): with `resize: none` on API < 35, `keyboardHeight` is the raw IME inset from the window bottom and overstates the part of the WebView the keyboard actually covers by the navigation-bar height

Aperta
  • Qualcosa non va?
#2,615 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
66/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
android, java
Ambito
backend, mobile

Direzione di ricerca

Start with Keyboard.java at the reported lines 97, 106, 119, and 124, and trace how the IME and navigation bar insets relate to the WebView bounds on API levels below 35. Check the existing keyboard event tests and run the Android plugin tests. Done means keyboardHeight reflects the portion of the WebView covered by the keyboard across API levels, including both will-show and did-show events.

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

Descrizione

triage
Plugin

Keyboard 8.0.6

Current Behavior

Keyboard.java L97 / L106 (and L119 / L124 for the did-show pair):

int imeHeight = insets.getInsets(WindowInsetsCompat.Type.ime()).bottom;
...
keyboardEventListener.onKeyboardEvent(EVENT_KB_WILL_SHOW, Math.round(imeHeight / density));

ime().bottom is measured from the bottom of the window. On API < 35 (no enforced edge-to-edge) the WebView ends above the navigation bar, so the keyboard covers imeHeight − navigationBarHeight of it, but the plugin reports imeHeight. An app that uses resize: none and moves its own composer by keyboardHeight (the documented way to animate with the keyboard) leaves a gap the size of the navigation bar (≈ 48 dp on a 3-button bar, ≈ 24 dp with gesture navigation) between the composer and the keyboard. On API 35+ the WebView reaches the window bottom and the number is right, so the same app behaves differently per OS version.

Measured on the Android 14 emulator (API 34, Pixel 6 profile, 1080×2400 @ 420 dpi, density 2.625, Gboard, 3-button navigation), windowSoftInputMode="adjustNothing", keyboard open on a field inside the WebView, read from dumpsys window and dumpsys activity top:

px dp
IME inset (type=ime frame=[0,1517][1080,2400], measured from the window bottom) — what L97/L106 report 883 336
navigation bar (type=navigationBars frame=[0,2274][1080,2400]) 126 48
WebView (CapacitorWebView 0,0-1080,2274, window frame=[0,0][1080,2400]) ends above the bar — —
part of the WebView the keyboard actually covers (2274 − 1517) 757 288

With @capacitor/keyboard 8.0.6 unmodified, the keyboardWillShow / keyboardDidShow payload on that run was {keyboardHeight: 336}. So keyboardHeight arrives as 336 while the keyboard covers 288 of the WebView's 867 CSS px; a composer moved up by keyboardHeight floats 48 dp above the keyboard. (The same WebView on an API 35 device reaches the window bottom, and 336 would be right there.)

Expected Behavior

keyboardHeight describes how much of the WebView the keyboard covers, the same on every API level.

Lingua principale
Java
Stelle
685
Fork
691
Merge medio
16h 33m
PR unite (30g)
1

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.