Questo problema esiste da un paio di mesi e riesco a riprodurlo qui in Meta utilizzando un dispositivo Android/Chrome (entrambi all’ultima versione) — in realtà, si verifica da diversi mesi, da gennaio circa.
L’editor dei messaggi sembra “bloccarsi” di tanto in tanto quando si seleziona un’emoji proposta.
Passaggi per la riproduzione:
Pubblica una risposta a un argomento e aggiungi del testo
Inizia ad aggiungere un pollice in alto digitando “:+1” e poi tocca l’emoji proposta
Cosa succede:
L’editor sembra in qualche modo bloccarsi o ridisegnarsi. Di solito viene perso parte del testo scritto.
Non è una riproduzione al 100%, ma riesco a riscontrare facilmente il problema entro un minuto di prove.
Ma ho aggiunto diversi breakpoint e non riesco a capire davvero “chi” sta mutando autocompleteOptions e impostandolo a null.
Il fatto che autocompleteOptions provenga dall’ambito della closure genitore di due livelli sopra è anche piuttosto strano e rende il codice un po’ difficile da seguire e debuggare.
@ljpp / @falco riuscite ancora a riprodurre questo bug? Ho provato molte varianti nell’inserimento di un emoji, ma non sono mai riuscito a riprodurlo. Se riuscite ancora a riprodurlo, potreste condividere i passaggi esatti, per favore? Grazie!
Ho appena provato e non sono riuscito a riprodurlo facilmente. Sono però abbastanza sicuro di averlo visto diverse volte durante l’estate, per caso mentre scrivevo un vero post.
Modifica: Chiederò alla nostra community se possono fornire una copertura dei test più estesa.
Modifica 2: Ah sì, ora l’ho riprodotto io stesso. La nostra community sta ora testando e sembra ci siano altri casi di riproduzione da parte di utenti regolari.
Sì, persiste. Personalmente non sono riuscito a riprodurlo dopo 15 minuti di tentativi aggressivi, quindi ho chiesto supporto alla nostra community. Diversi utenti sono riusciti a riprodurlo e uno ha persino fornito la prova con uno screenshot. I sintomi sono invariati: una volta toccata l’emoji del pollice in su nel selettore, la tastiera si ripiega e viene perso del contenuto scritto nell’editor.
In passato riuscivo a riprodurlo molto facilmente, ma ora non riesco più a individuarlo con certezza. Quindi il problema esiste, ma non è riproducibile al 100%. Continueremo a fare tentativi per capire se esiste una sequenza di azioni nell’interfaccia che innesca questo comportamento.
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?