Ok, j’ai réexaminé la situation aujourd’hui et j’ai réussi à reproduire le problème après avoir basculé le clavier virtuel de mon téléphone sur Gboard. Gboard déclenche parfois les événements keydown et keyup deux fois pour une seule pression de touche, et si cela se produit pour la dernière touche que vous appuyez avant de sélectionner un emoji dans l’autocomplétion, vous obtiendrez un crash.
Je ne suis pas sûr de ce qui cause Gboard à déclencher ces événements deux fois, mais cela semble dépendre de ce que vous avez tapé et de vos paramètres Gboard.
Les doubles événements provoquent un crash en raison de la façon dont notre bibliothèque d’autocomplétion est conçue. Ainsi, la bibliothèque écoute les événements keydown et keyup, et lors de keydown, elle efface les suggestions d’autocomplétion et lors de keyup, elle propose de nouvelles suggestions basées sur le nouveau terme d’autocomplétion.
Cependant, il existe une petite protection/optimisation pour empêcher la bibliothèque d’effectuer un travail en double lorsque le terme n’a pas changé depuis les suggestions précédentes, et c’est là que le problème se produit. La première paire d’événements keydown et keyup efface les anciennes suggestions et en propose de nouvelles comme prévu, mais la seconde paire erronée effacera à nouveau les suggestions lors de keydown mais n’en proposera pas de nouvelles lors de keyup car le terme d’autocomplétion n’a pas changé.
La seule “correction” la moins “hacky” à laquelle je puisse penser est de supprimer la protection/optimisation afin que la bibliothèque propose toujours de nouvelles suggestions lors de keyup, mais je ne suis pas sûr si cela est souhaitable ou si cela en vaut la peine.
Je sais que nous voulons réécrire notre bibliothèque d’autocomplétion à un moment donné (c’est une partie du code le plus ancien de la base de code et elle a désespérément besoin d’une réécriture), donc peut-être que ce bug pourrait attendre jusqu’à ce que nous arrivions à la réécriture ?