Emoji-Auswahl stürzt den Nachrichten-Editor in Android / Chrome ab

Fehler
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 „Gefällt mir“
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 „Gefällt mir“
4

Android 11/Chrome 89, the latest available.

1 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
20

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

21

Ich habe es gerade ohne Absicht reproduziert.

Firefox 94.1.1 (Build #2015842491)

Und Chrome 95.0.4638.74

2 „Gefällt mir“
22

Ich glaube, dass Emoji-Selektoren, die nicht von der Plattform stammen, hier das eigentliche Problem sind. :wink: Der triviale Workaround ist, den nativen Emoji-Picker Ihres Betriebssystems zu verwenden?

23

Es gibt normalerweise eine Problemumgehung. Nicht immer, zum Beispiel können benutzerdefinierte Emojis in Discourse verwendet werden.

In jedem Fall ist das Neuladen der Seite und der Verlust geschriebener Inhalte ein schlechtes Verhalten, das wir beheben sollten.

24

Ok, ich habe mir das heute noch einmal angesehen und konnte es reproduzieren, nachdem ich die virtuelle Tastatur auf meinem Handy auf Gboard umgestellt hatte. Gboard löst manchmal keydown- und keyup-Ereignisse zweimal für einen einzelnen Tastendruck aus, und wenn dies für die letzte Taste geschieht, die Sie drücken, bevor Sie ein Emoji aus der Autovervollständigung auswählen, kommt es zu einem Absturz.

Ich bin mir nicht sicher, was Gboard dazu veranlasst, diese Ereignisse zweimal auszulösen, aber es scheint davon abzuhängen, was Sie eingegeben haben und welche Gboard-Einstellungen Sie haben.

Die doppelten Ereignisse verursachen einen Absturz aufgrund der Art und Weise, wie unsere Autovervollständigungsbibliothek konzipiert ist. Die Bibliothek lauscht also sowohl auf keydown- als auch auf keyup-Ereignisse. Bei keydown löscht sie die Autovervollständigungsvorschläge und bei keyup bietet sie neue Vorschläge basierend auf dem neuen Autovervollständigungsbegriff an.

Es gibt jedoch eine kleine Schutzmaßnahme/Optimierung, um die Bibliothek vor doppelter Arbeit zu schützen, wenn sich der Begriff seit den vorherigen Vorschlägen nicht geändert hat, und hier tritt das Problem auf. Das erste Paar von keydown- und keyup-Ereignissen löscht die alten Vorschläge und bietet wie erwartet neue an, aber das zweite fehlerhafte Paar löscht die Vorschläge bei keydown erneut, bietet aber bei keyup keine neuen an, da sich der Autovervollständigungsbegriff nicht geändert hat.

Die einzige am wenigsten umständliche “Lösung”, die mir einfällt, ist, die Schutzmaßnahme/Optimierung zu entfernen, damit die Bibliothek bei keyup immer neue Vorschläge anbietet, aber ich bin mir nicht sicher, ob dies gewünscht oder lohnenswert ist.

Ich weiß, dass wir unsere Autovervollständigungsbibliothek irgendwann neu schreiben wollen (sie ist einer der ältesten Codes in der Codebasis und braucht dringend eine Überarbeitung), also könnte dieser Fehler vielleicht warten, bis wir zur Überarbeitung kommen?

5 „Gefällt mir“
25

Ist der Absturz eine Art „Endlosschleife“? Können wir einfach verfolgen, dass wir eine Feedbackschleife erreicht haben und die Dinge bereinigen?

1 „Gefällt mir“
26

Nein, der Absturz greift auf eine Nullvariable zu. Wenn die Vorschläge gelöscht werden, wird die Variable autocompleteOptions auf null gesetzt, und wenn Sie dann auf einen der gerenderten Vorschläge tippen, erwarten wir, dass autocompleteOptions ein Array ist, aber es ist null.

Das bringt mich auf eine weitere Idee: Vielleicht könnten wir prüfen, ob autocompleteOptions null ist, wenn ein Vorschlag ausgewählt wird, und wenn die Variable null ist, dann rufen wir die Vorschläge für den gegebenen Begriff erneut ab?

2 „Gefällt mir“
27

Ja, das klingt nach einer guten Übergangslösung.

2 „Gefällt mir“
28

Ah, ich fühle mich so dumm, dass ich dieses Detail nicht gemeldet habe. Mein vorheriges Telefon war ein reines Android One, daher hatte es Gboard als Standard und es hat mich seitdem auf das nächste Gerät (Sammy A42 5G) begleitet. Aber die meisten heute verkauften Android-Geräte verwenden standardmäßig eine Tastatur-App von Drittanbietern.

Toll, diese Fortschritte zu sehen.

2 „Gefällt mir“
29

Ich habe meine Korrektur für diesen Fehler zusammengeführt:

Die Korrektur wurde auf Meta und auf Ihrer Website @ljpp bereitgestellt. Lassen Sie mich wissen, ob Ihre Benutzer dies immer noch reproduzieren können.

5 „Gefällt mir“