El selector de emojis bloquea el editor de mensajes en Android / Chrome

Error
1

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:

  1. Post a reply to a topic, add some text
  2. Start adding a thumbs up by typing “:+1” and then tap the proposed emoji :+1:

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.

2 Me gusta
2

What exact version of Android/ Chrome are you using?

3

I can reproduce. Follows the stack trace:

_application-bfbda341c2eb6dd7d61c681e17bdccec057c30e045ddc332927a7363150e9b1b.js:16386 Uncaught TypeError: Cannot read property '0' of null
    at HTMLLIElement.<anonymous> (application-bfbda341c2eb6dd7d61c681e17bdccec057c30e045ddc332927a7363150e9b1b.br.js:1)
    at HTMLLIElement.dispatch (ember_jquery-36a23101c869ab0dc53fc908de69adb785731593573d32bdeef416acc1076ef4.br.js:1)
    at HTMLLIElement.d.handle (ember_jquery-36a23101c869ab0dc53fc908de69adb785731593573d32bdeef416acc1076ef4.br.js:1)
(anonymous) @ application-bfbda341c2eb6dd7d61c681e17bdccec057c30e045ddc332927a7363150e9b1b.br.js:1
dispatch @ ember_jquery-36a23101c869ab0dc53fc908de69adb785731593573d32bdeef416acc1076ef4.br.js:1
d.handle @ ember_jquery-36a23101c869ab0dc53fc908de69adb785731593573d32bdeef416acc1076ef4.br.js:1

That is this line

https://github.com/discourse/discourse/blob/master/app/assets/javascripts/discourse/app/lib/autocomplete.js#L308

Error happens because selectedOption is 0 (single suggestion aka the first) while autocompleteOptions is somehow null.

Investigating why now…

So I’m not sure why so far. At first I was suspecting this PR from @Osama

https://github.com/discourse/discourse/pull/11637

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.

8 Me gusta
4

Android 11/Chrome 89, the latest available.

1 me gusta
11

@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!

1 me gusta
12

Yes, it still crashes on Chrome Android for me. You must follow the instructions 100% for it to repro, as it’s very specific.

1 me gusta
15

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.

1 me gusta
16

Just reproed this accidentally, so this is still open.

18

We still have this on our list, we are just finding this fiendishly hard to reproduce and debug.

I can’t really put a pr-welcome on this cause it is way too hard. We will revisit this at some point, putting a 6 months timer on it.

Is this issue still persisting?

19

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.

1 me gusta
20

Can you ask someone that can reproduce it, to see if they can do it on try.discourse.org

21

Lo acabo de reproducir sin intentarlo.

Firefox 94.1.1 (Build #2015842491)

Y Chrome 95.0.4638.74

2 Me gusta
22

Siento que los selectores de emojis de plataformas no nativas sean el verdadero error aquí. :wink: ¿La solución trivial es usar el selector de emojis nativo de tu sistema operativo preferido?

23

Claro que suele haber una solución alternativa. No siempre, por ejemplo, puede haber emojis personalizados en uso en Discourse.

De cualquier manera, recargar la página y perder el contenido escrito es un comportamiento deficiente que deberíamos solucionar.

24

Ok, he vuelto a revisar esto hoy y logré reproducirlo después de cambiar el teclado virtual de mi teléfono a Gboard. Gboard a veces dispara los eventos keydown y keyup dos veces por una sola pulsación de tecla y si eso sucede con la última tecla que presionas antes de seleccionar un emoji del autocompletado, obtendrás un error.

No estoy seguro de qué causa que Gboard dispare estos eventos dos veces, pero parece depender de lo que hayas escrito y de tu configuración de Gboard.

Los eventos dobles causan un error debido a la forma en que está diseñada nuestra biblioteca de autocompletado. La biblioteca escucha los eventos keydown y keyup, y en keydown borra las sugerencias de autocompletado y en keyup ofrece nuevas sugerencias basadas en el nuevo término de autocompletado.

Sin embargo, hay una pequeña protección/optimización para evitar que la biblioteca realice trabajo duplicado cuando el término no ha cambiado desde las sugerencias anteriores, y aquí es donde ocurre el problema. El primer par de eventos keydown y keyup borra las sugerencias antiguas y ofrece nuevas como se esperaba, pero el segundo par erróneo borrará las sugerencias nuevamente en keydown pero no ofrecerá nuevas en keyup porque el término de autocompletado no ha cambiado.

La única “solución” menos improvisada que se me ocurre es eliminar la protección/optimización para que la biblioteca siempre ofrezca nuevas sugerencias en keyup, pero no estoy seguro de si esto es deseable o vale la pena.

Sé que queremos reescribir nuestra biblioteca de autocompletado en algún momento (es uno de los códigos más antiguos de la base de código y necesita desesperadamente una reescritura), así que tal vez este error podría esperar hasta que lleguemos a la reescritura.

5 Me gusta
25

¿El bloqueo es una especie de “bucle infinito”? ¿Podemos simplemente rastrear que hemos entrado en un bucle de retroalimentación y limpiar las cosas?

1 me gusta
26

No, el bloqueo se debe al acceso a una variable nula. Cuando se borran las sugerencias, la variable autocompleteOptions se establece en null y luego, cuando se toca una de las sugerencias renderizadas, esperamos que autocompleteOptions sea un array, pero es null.

Esto me da otra idea: ¿quizás podríamos comprobar si autocompleteOptions es null cuando se selecciona una sugerencia y, si la variable es null, volver a obtener las sugerencias para el término dado?

2 Me gusta
27

Sí, esto suena como una buena solución alternativa.

2 Me gusta
28

Ah, me siento tan tonto por no haber informado este detalle. Mi teléfono anterior era un Android One limpio, por lo que tenía Gboard por defecto, y me ha seguido desde entonces al siguiente dispositivo (Sammy A42 5G). Pero la mayoría de los dispositivos Android que se venden hoy en día usan una aplicación de teclado de terceros por defecto.

Genial ver este progreso.

2 Me gusta
29

He fusionado mi solución para este error:

La solución se ha implementado en Meta y en tu sitio @ljpp, hazme saber si tus usuarios aún pueden reproducirlo.

5 Me gusta