Este problema existe há alguns meses, e consigo reproduzi-lo aqui na Meta usando um dispositivo Android/Chrome (ambos na versão mais recente) — na verdade, isso vem acontecendo há vários meses, desde janeiro ou por aí.
O editor de mensagens parece “travar” de vez em quando quando se escolhe um emoji sugerido.
Passos para reproduzir:
Publique uma resposta em um tópico e adicione algum texto
Comece a adicionar um polegar para cima digitando “:+1” e depois toque no emoji sugerido
O que acontece:
O editor parece travar de alguma forma ou é redesenhado. Geralmente, algum texto escrito é perdido.
Não é 100% reproduzível, mas consigo encontrar o problema facilmente em menos de um minuto de testes.
Mas adicionei vários pontos de interrupção e não consegui realmente descobrir “quem” está mutando autocompleteOptions e definindo-o como null.
Ter autocompleteOptions vindo do escopo do fechamento pai, dois níveis acima, também é bastante estranho e torna o código um pouco difícil de seguir e depurar.
@ljpp / @falco, vocês ainda conseguem reproduzir esse bug? Tentei várias variações de inserir um emoji e não consegui reproduzir nem uma única vez. Se vocês ainda conseguirem reproduzir, por favor, compartilhem os passos exatos. Obrigado!
Acabei de tentar e não consegui reproduzir facilmente isso. No entanto, tenho bastante certeza de que vi isso algumas vezes durante o verão, acidentalmente, ao digitar uma postagem real.
Edição: Vou perguntar à nossa comunidade se eles podem fornecer uma cobertura de teste mais extensa.
Edição 2: Ah, sim, consegui reproduzir isso agora. Nossa comunidade está testando e parece que há mais reproduções por usuários comuns.
Sim, persiste. Pessoalmente, não consegui reproduzi-lo após 15 minutos de testes intensivos, então pedi apoio à nossa comunidade. Vários usuários conseguiram reproduzir o erro e um deles até provou com uma captura de tela. Os sintomas permanecem inalterados: ao tocar no emoji de “joinha” no seletor, o teclado se recolhe e parte do conteúdo digitado é perdida no editor.
Antes eu conseguia reproduzir isso muito facilmente, mas agora não consigo mais acertar o momento. O problema existe, mas não é reproduzível em 100% dos casos. Vamos continuar testando para tentar descobrir se há alguma etapa na interface que desencadeia isso.
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?