Android/Chromeで絵文字セレクターがメッセージエディタをクラッシュさせる

バグ
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
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
4

Android 11/Chrome 89, the latest available.

「いいね！」 1
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
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
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
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
20

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

21

試さなくても再現できました。

Firefox 94.1.1 (ビルド #2015842491)

Chrome 95.0.4638.74

「いいね！」 2
22

ネイティブではないプラットフォームの絵文字セレクターが本当のバグだと思います。 :wink: 簡単な回避策は、お使いのOSのネイティブ絵文字ピッカーを使用することですか？

23

通常、回避策はあります。ただし、常にそうとは限りません。たとえば、Discourse でカスタム絵文字が使用されている場合があります。

いずれにしても、ページをリロードして記述されたコンテンツを失うのは、修正すべき悪い動作です。

24

はい、本日再度確認したところ、スマートフォンの仮想キーボードをGboardに切り替えた後に再現させることができました。Gboardは、キーを1回押しただけでkeydownとkeyupイベントを2回発生させることがあります。もし、絵文字をオートコンプリートから選択する直前に押した最後のキーでこれが発生すると、クラッシュします。

Gboardがこれらのイベントを2回発生させる原因は不明ですが、入力内容やGboardの設定に依存するようです。

この二重イベントは、オートコンプリートライブラリの設計上の理由でクラッシュを引き起こします。ライブラリはkeydownとkeyupの両方のイベントをリッスンし、keydownでオートコンプリートの候補をクリアし、keyupで新しいオートコンプリート用語に基づいて新しい候補を提供します。

しかし、用語が以前の候補から変更されていない場合にライブラリが重複作業を行うのを防ぐための小さなガード/最適化があり、ここで問題が発生します。最初のkeydownとkeyupイベントのペアは、予想どおり古い候補をクリアして新しい候補を提供しますが、2番目の誤ったペアはkeydownで候補を再度クリアしますが、オートコンプリート用語が変更されていないため、keyupで新しい候補を提供しません。

考えられる最もハック的でない「修正」は、ガード/最適化を削除して、ライブラリが常にkeyupで新しい候補を提供することですが、これが望ましいかどうか、またはそれだけの価値があるかどうかはわかりません。

いつかオートコンプリートライブラリを書き直したいということは知っています（コードベースの中で最も古いコードの一部であり、書き直しが desperately 必要です）、なので、このバグは書き直しに着手するまで待つことができるかもしれません。

「いいね！」 5
25

クラッシュは一種の「無限ループ」ですか？フィードバックループに陥ったことを追跡して、すべてをクリアすることはできませんか？

「いいね！」 1
26

いいえ、クラッシュはヌル変数にアクセスしています。サジェストがクリアされると autocompleteOptions 変数がヌルに設定され、レンダリングされたサジェストのいずれかをタップしたときに autocompleteOptions が配列であることを期待しますが、実際にはヌルです。

これにより、別のアイデアが浮かびました。サジェストが選択されたときに autocompleteOptions がヌルかどうかを確認し、変数がヌルの場合は、指定された用語のサジェストを再取得することはできませんか？

「いいね！」 2
27

はい、これは良い回避策のように思えます。

「いいね！」 2
28

ああ、この詳細を報告しなかったなんて、自分が愚かに思えます。以前使っていたスマホは、標準でGboardが搭載されているクリーンなAndroid Oneだったので、それがずっと次のデバイス（Sammy A42 5G）にも引き継がれてきました。しかし、今日販売されているAndroidデバイスのほとんどは、デフォルトでサードパーティ製のキーボードアプリを使用しています。

この進歩を見られて嬉しいです。

「いいね！」 2
29

このバグの修正をマージしました。

この修正はMetaとあなたのサイト@ljppにデプロイされました。ユーザーがまだ再現できるか教えてください。

「いいね！」 5