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

Abierto
  • ¿Algo no está bien?
#2,615 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 29 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
66/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
android, java
Área
backend, mobile

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Java
Estrellas
688
Forks
692
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ionic-team/capacitor-plugins

Todos los issues de ionic-team/capacitor-plugins

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.