Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

bug(keyboard): Android `WindowInsetsAnimationCompat.Callback` does not filter by `Type.ime()` — any inset animation re-emits keyboardWillShow/keyboardDidShow (or the hide pair) with the current IME state

Abierto Apto para principiantes
  • ¿Algo no está bien?
#2,616 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

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

Línea de trabajo

Empieza en Keyboard.java, cerca de onStart(animation, bounds) y onEnd(animation), donde el issue indica que no se comprueba la máscara del tipo de animación. Inspecciona cómo WindowInsetsAnimationCompat expone su máscara de tipos y cómo los callbacks existentes emiten eventos del teclado. El trabajo estará terminado cuando las animaciones que no estén relacionadas con Type.ime() no produzcan eventos del teclado, mientras que las animaciones IME sigan produciendo los eventos esperados de mostrar y ocultar.

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 L90–128: onStart(animation, bounds) (L90) and onEnd(animation) (L114) never inspect animation.getTypeMask(). For every WindowInsetsAnimation dispatched to the root view they read insets.isVisible(Type.ime()) and emit:

  • keyboardWillShow + keyboardDidShow (with the current IME height) if the keyboard happens to be visible,
  • keyboardWillHide + keyboardDidHide otherwise.

So an animation of the system bars (immersive mode toggling, navigation-bar hide/show, a status-bar animation triggered by an overlay) while the keyboard is open replays a full show sequence to JS although the keyboard did not move; with the keyboard closed it replays a hide sequence although nothing was open.

Observed on the Android 14 emulator (API 34, Pixel 6 profile, 1080×2400 @ 420 dpi, Gboard, 3-button navigation), app with @capacitor/keyboard 8.0.6 and @capacitor/status-bar 8.0.4, listeners on all four events, trigger = StatusBar.hide() followed 1.2 s later by StatusBar.show() (both animate the status-bar inset through WindowInsetsControllerCompat; the keyboard itself was not touched):

Keyboard open and settled (keyboardHeight: 336 had been reported once):

ms after hide() event payload
40 keyboardWillShow {keyboardHeight: 336}
1241 keyboardDidShow {keyboardHeight: 336}
1251 keyboardWillShow {keyboardHeight: 336}
1766 keyboardDidShow {keyboardHeight: 336}

Keyboard closed:

ms after hide() event
30 keyboardWillHide
1219 keyboardDidHide
1230 keyboardWillHide
1747 keyboardDidHide

Four keyboard events per status-bar round trip in both states, with nothing having changed about the keyboard. An app that animates its composer on keyboardWillShow/keyboardWillHide re-runs that animation each time (and, with the keyboard closed, runs a hide ride for a keyboard that was never open).

Expected Behavior

Keyboard events describe the keyboard: an animation of the status or navigation bars, with the keyboard not moving, produces none.

Lenguaje dominante
Java
Estrellas
685
Forks
691
Merge medio
16 h 33 min
PR fusionados (30 d)
1

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.