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.
Sinto que os seletores de emoji de plataforma não nativos são o verdadeiro bug aqui. A solução trivial é usar o seletor de emoji nativo do seu sistema operacional de preferência?
Ok, analisei isso novamente hoje e consegui reproduzir o problema depois de mudar o teclado virtual do meu telefone para o Gboard. O Gboard às vezes dispara eventos keydown e keyup duas vezes para uma única pressionada de tecla e, se isso acontecer para a última tecla que você pressiona antes de selecionar um emoji da autocompletar, você terá um travamento.
Não tenho certeza do que causa o Gboard a disparar esses eventos duas vezes, mas parece depender do que você digitou e das suas configurações do Gboard.
Os eventos duplos causam um travamento devido à forma como nossa biblioteca de autocompletar é projetada. Assim, a biblioteca escuta os eventos keydown e keyup, e no keydown ela limpa as sugestões de autocompletar e no keyup ela oferece novas sugestões com base no novo termo de autocompletar.
No entanto, há uma pequena proteção/otimização para proteger a biblioteca de fazer trabalho duplicado quando o termo não mudou desde as sugestões anteriores, e é aqui que o problema ocorre. O primeiro par de eventos keydown e keyup limpa as sugestões antigas e oferece novas como esperado, mas o segundo par errôneo limpará as sugestões novamente no keydown, mas não oferecerá novas no keyup porque o termo de autocompletar não mudou.
A única “correção” menos improvisada que consigo pensar é remover a proteção/otimização para que a biblioteca sempre ofereça novas sugestões no keyup, mas não tenho certeza se isso é desejado ou se vale a pena.
Eu sei que queremos reescrever nossa biblioteca de autocompletar em algum momento (é um dos códigos mais antigos na base de código e desesperadamente precisa de uma reescrita), então talvez esse bug possa esperar até chegarmos à reescrita?
Não, a falha está acessando uma variável nula. Quando as sugestões são limpas, a variável autocompleteOptions é definida como nula e, em seguida, quando você toca em uma das sugestões renderizadas, esperamos que autocompleteOptions seja um array, mas é nulo.
Isso me dá outra ideia: talvez possamos verificar se autocompleteOptions é nulo quando uma sugestão é selecionada e, se a variável for nula, então podemos buscar novamente as sugestões para o termo fornecido?
Ah, me sinto tão burro por não ter relatado esse detalhe. Meu telefone anterior era um Android One limpo, então ele tinha o Gboard como padrão, e ele me acompanhou desde então para o próximo dispositivo (Sammy A42 5G). Mas a maioria dos dispositivos Android vendidos hoje usa um aplicativo de teclado de terceiros por padrão.
A solução trivial é usar o seletor de emoji nativo do seu sistema operacional de preferência?