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.
Mi sembra che i selettori di emoji non nativi della piattaforma siano il vero bug qui. La soluzione banale è usare il selettore di emoji nativo del tuo sistema operativo preferito?
Ok, ho riesaminato la questione oggi e sono riuscito a riprodurre il problema dopo aver cambiato la tastiera virtuale sul mio telefono in Gboard. Gboard a volte genera eventi keydown e keyup due volte per una singola pressione del tasto e se ciò accade per l’ultimo tasto premuto prima di selezionare un emoji dall’autocompletamento, si verificherà un crash.
Non sono sicuro di cosa causi a Gboard la generazione di questi eventi due volte, ma sembra dipendere da ciò che hai digitato e dalle tue impostazioni di Gboard.
I doppi eventi causano un crash a causa del modo in cui è progettata la nostra libreria di autocompletamento. Quindi la libreria ascolta sia gli eventi keydown che keyup, e su keydown cancella i suggerimenti di autocompletamento e su keyup offre nuovi suggerimenti basati sul nuovo termine di autocompletamento.
Tuttavia, c’è una piccola protezione/ottimizzazione per evitare che la libreria esegua lavoro duplicato quando il termine non è cambiato rispetto ai suggerimenti precedenti, ed è qui che si verifica il problema. La prima coppia di eventi keydown e keyup cancella i vecchi suggerimenti e ne offre di nuovi come previsto, ma la seconda coppia errata cancellerà nuovamente i suggerimenti su keydown ma non ne offrirà di nuovi su keyup perché il termine di autocompletamento non è cambiato.
L’unica “correzione” meno “hacky” a cui riesco a pensare è rimuovere la protezione/ottimizzazione in modo che la libreria offra sempre nuovi suggerimenti su keyup, ma non sono sicuro se questo sia desiderato o ne valga la pena.
So che vogliamo riscrivere la nostra libreria di autocompletamento a un certo punto (è uno dei codici più vecchi nel codebase e ha disperatamente bisogno di una riscrittura), quindi forse questo bug potrebbe aspettare finché non arriveremo alla riscrittura?
No, il crash sta accedendo a una variabile nulla. Quando i suggerimenti vengono cancellati, la variabile autocompleteOptions viene impostata su null e poi, quando si tocca uno dei suggerimenti renderizzati, ci aspettiamo che autocompleteOptions sia un array ma è null.
Questo mi dà un’altra idea: forse potremmo verificare se autocompleteOptions è null quando viene selezionato un suggerimento e, se la variabile è null, allora potremmo recuperare nuovamente i suggerimenti per il termine dato?
Ah, mi sento così stupido per non aver segnalato questo dettaglio. Il mio telefono precedente era un Android One pulito, quindi aveva Gboard come predefinito, ed è rimasto con me da allora sul dispositivo successivo (Sammy A42 5G). Ma la maggior parte dei dispositivi Android venduti oggi utilizza un’app di tastiera di terze parti per impostazione predefinita.
La soluzione banale è usare il selettore di emoji nativo del tuo sistema operativo preferito?