This issue has been around for couple of months, and I can reproduce it here at Meta using an Android/Chrome device (both latest) – actually this has been happening for several months, since January or so.
The message editor seems to “crash” every now and then when one chooses a proposed emoji.
Repro steps:
Post a reply to a topic, add some text
Start adding a thumbs up by typing “:+1” and then tap the proposed emoji
What happens:
The editor seems to somehow crash, or is redrawn. Some written text is typically lost.
It is not a 100% repro, but I can easily hit the issue within a minute of fiddling.
But I added quite a few breakpoints and can’t really find “who” is mutating autocompleteOptions and setting it as null.
Having autocompleteOptions be from the scope of the parent closure from two levels up is also quite weird and makes the code a bit hard to follow up/debug.
@ljpp / @falco can you still repro this bug? I’ve tried lots of variations of inserting an emoji and couldn’t repro not even once. If you can still repro, can you share the exact steps please? Thanks!
Just tried and could not easily reproduce this. I am however quite certain that I have seen this over the summer a couple of times, accidentally when typing a real post.
Edit: I’ll ask our community if they could provide more extensive test coverage.
Edit 2: Oh yes, I reproed it myself now. Our community is now testing and looks like there are some more repros by regular users.
Yes it is. Personally I could not reproduce it with 15 minutes of aggressive fiddling, so I asked our community for support. Several users were able to repro and one even proved it with a screenshot. Symptoms are unchanged - once you tap the thumb up -emoji on the selector, the keyboard folds away, and some written content is lost in the editor.
I used to repro this very easily, but now I can’t seem to nail it. So the issue is there, but it is not a 100% repro. We will keep on fiddling and trying to figure out if there is some UI-step that triggers this.
J’ai l’impression que les sélecteurs d’emoji non natifs de la plateforme sont le vrai bug ici. La solution de contournement triviale est d’utiliser le sélecteur d’emoji natif de votre système d’exploitation ?
Bien sûr, il existe généralement une solution de contournement. Pas toujours, par exemple, il peut y avoir des emoji personnalisés utilisés sur Discourse.
Quoi qu’il en soit, recharger la page et perdre le contenu écrit est un comportement médiocre que nous devrions corriger.
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 ?
Le crash est-il une sorte de « boucle infinie » ? Pouvons-nous simplement suivre le fait que nous venons de rencontrer une boucle de rétroaction et tout nettoyer ?
Non, le crash accède à une variable nulle. Lorsque les suggestions sont effacées, la variable autocompleteOptions est définie sur null, puis lorsque vous appuyez sur l’une des suggestions rendues, nous nous attendons à ce que autocompleteOptions soit un tableau, mais il est null.
Cela me donne une autre idée : peut-être pourrions-nous vérifier si autocompleteOptions est null lorsqu’une suggestion est sélectionnée et si la variable est null, alors nous récupérons à nouveau les suggestions pour le terme donné ?
Ah, je me sens tellement bête de ne pas avoir signalé ce détail. Mon téléphone précédent était un Android One épuré, il avait donc Gboard par défaut, et il m’a suivi depuis lors sur mon appareil suivant (Sammy A42 5G). Mais la plupart des appareils Android vendus aujourd’hui utilisent une application de clavier tierce par défaut.
La solution de contournement triviale est d’utiliser le sélecteur d’emoji natif de votre système d’exploitation ?