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

Dieses Problem besteht seit einigen Monaten, und ich kann es hier bei Meta mit einem Android/Chrome-Gerät (beide auf dem neuesten Stand) reproduzieren – tatsächlich tritt es seit Januar, also seit mehreren Monaten, auf.

Der Nachrichten-Editor scheint gelegentlich „abzustürzen", wenn man ein vorgeschlagenes Emoji auswählt.

Reproduktionsschritte:

  1. Antworten Sie auf ein Thema und fügen Sie etwas Text hinzu.
  2. Beginnen Sie, ein Daumen-hoch-Emoji einzufügen, indem Sie „:+1" tippen, und tippen Sie dann auf das vorgeschlagene Emoji :+1:.

Was passiert:

Der Editor scheint irgendwie abzustürzen oder wird neu gezeichnet. Dabei geht normalerweise etwas geschriebener Text verloren.

Es lässt sich nicht zu 100 % reproduzieren, aber ich kann das Problem innerhalb einer Minute durch Ausprobieren leicht auslösen.

2 „Gefällt mir“

Welche genaue Version von Android/Chrome verwenden Sie?

Ich kann den Fehler reproduzieren. Hier ist der 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

Das ist diese Zeile:

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

Der Fehler tritt auf, weil selectedOption 0 ist (ein einziger Vorschlag, also der erste), während autocompleteOptions irgendwie null ist.

Ich untersuche gerade, warum das so ist…

Bislang bin ich mir nicht sicher, warum das passiert. Anfangs habe ich diesen PR von @Osama verdächtigt:

Aber ich habe einige Breakpoints hinzugefügt und kann nicht wirklich herausfinden, “wer” autocompleteOptions mutiert und auf null setzt.

Dass autocompleteOptions aus dem Bereich des übergeordneten Closures zwei Ebenen höher stammt, ist ebenfalls ziemlich seltsam und macht den Code etwas schwerer nachvollziehbar und zu debuggen.

8 „Gefällt mir“

Android 11/Chrome 89, die aktuellste verfügbare Version.

1 „Gefällt mir“

@ljpp / @falco, könnt ihr diesen Fehler immer noch reproduzieren? Ich habe viele Variationen des Einfügens eines Emojis ausprobiert und konnte ihn nicht einmal reproduzieren. Wenn ihr ihn immer noch reproduzieren könnt, könntet ihr bitte die genauen Schritte teilen? Danke!

1 „Gefällt mir“

Ja, es stürzt bei mir immer noch auf Chrome Android ab. Sie müssen die Anweisungen zu 100 % befolgen, damit es reproduzierbar ist, da es sehr spezifisch ist.

1 „Gefällt mir“

Habe es gerade versucht und konnte es nicht einfach reproduzieren. Ich bin mir jedoch ziemlich sicher, dass ich das über den Sommer ein paar Mal gesehen habe, versehentlich beim Verfassen eines echten Beitrags.

Edit: Ich werde unsere Community fragen, ob sie eine umfassendere Testabdeckung bereitstellen können.

Edit 2: Oh ja, ich habe es jetzt selbst reproduziert. Unsere Community testet gerade, und es scheint, dass es weitere Reproduktionen durch normale Nutzer gibt.

1 „Gefällt mir“

Ich habe das versehentlich neu reproduziert, daher ist es noch offen.

Das steht immer noch auf unserer Liste, wir haben jedoch große Schwierigkeiten, es nachzustellen und zu debuggen.

Ich kann hier wirklich keinen #pr-welcome-Tag anbringen, da es viel zu schwierig ist. Wir werden das irgendwann erneut prüfen und einen Sechs-Monats-Zeitraum dafür festlegen.

Besteht dieses Problem noch?

Ja, das tut es. Ich persönlich konnte es trotz 15 Minuten intensiver Tests nicht reproduzieren, daher habe ich unsere Community um Unterstützung gebeten. Mehrere Benutzer konnten das Problem nachstellen, und einer hat es sogar mit einem Screenshot bewiesen. Die Symptome bleiben unverändert: Sobald du auf das Daumen-hoch-Emoji im Auswahlfeld tippst, klappt die Tastatur zusammen, und im Editor gehen einige geschriebene Inhalte verloren.

Früher konnte ich das Problem sehr leicht reproduzieren, aber jetzt scheint es mir unmöglich, es gezielt auszulösen. Das Problem besteht also weiterhin, ist aber nicht zu 100 % reproduzierbar. Wir werden weiter experimentieren und versuchen herauszufinden, ob es einen bestimmten UI-Schritt gibt, der dies auslöst.

1 „Gefällt mir“

Kannst du jemanden, der das Problem nachstellen kann, bitten zu prüfen, ob es auch auf try.discourse.org funktioniert?

Ich habe es gerade ohne Absicht reproduziert.

Firefox 94.1.1 (Build #2015842491)

Und Chrome 95.0.4638.74

2 „Gefällt mir“

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?

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.

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“

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“

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“

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

2 „Gefällt mir“

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“

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“