Emoji选择器导致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 (Build #2015842491)

以及 Chrome 95.0.4638.74

2 个赞
22

我觉得非原生平台的表情符号选择器才是真正的问题所在。 :wink: 最简单的解决方法是，使用您选择的操作系统中的原生表情符号选择器？

23

当然，通常有一个变通办法。不一定总是如此，例如，Discourse 上可能正在使用自定义表情符号。

无论如何，重新加载页面并丢失已写内容是一种糟糕的行为，我们应该修复它。

24

好的，我今天又看了一下，在将手机上的虚拟键盘切换到 Gboard 后，我成功重现了这个问题。Gboard 有时会对单个按键操作触发两次 keydown 和 keyup 事件，如果这发生在您在从自动补全中选择表情符号之前按下的最后一个键，就会导致崩溃。

我不确定是什么原因导致 Gboard 触发这些事件两次，但这似乎取决于您输入的内容和您的 Gboard 设置。

这两个事件导致崩溃的原因在于我们的自动补全库的设计方式。该库会监听 keydown 和 keyup 事件，在 keydown 时清除自动补全建议，在 keyup 时根据新的自动补全词条提供新建议。

但是，有一个小的保护/优化措施可以防止库在词条自上次建议以来未更改时执行重复工作，而问题就出在这里。第一对 keydown 和 keyup 事件会按预期清除旧建议并提供新建议，但第二对错误的事件会在 keydown 时再次清除建议，但在 keyup 时不会提供新建议，因为自动补全词条没有改变。

我能想到的唯一最不“hacky”的“修复”方法是移除保护/优化措施，让库在 keyup 时始终提供新建议，但我不知道这是否是期望的，或者是否值得这样做。

我知道我们最终想要重写我们的自动补全库（它是代码库中最古老的部分之一，急需重写），所以也许这个 bug 可以等到我们重写的时候再处理？

5 个赞
25

这次崩溃是某种“无限循环”吗？我们能否简单地跟踪我们刚刚进入的反馈循环并清理事物？

1 个赞
26

不，崩溃是访问了一个空变量。当建议被清除时，autocompleteOptions 变量被设置为 null，然后当我们点击渲染的建议之一时，我们期望 autocompleteOptions 是一个数组，但它是 null。

这给了我另一个想法：也许我们可以在选择建议时检查 autocompleteOptions 是否为 null，如果变量为 null，那么我们为给定的术语重新获取建议？

2 个赞
27

是的，这听起来是一个不错的解决方法。

2 个赞
28

啊，我真笨，竟然没注意到这个细节。我的上一部手机是纯净版安卓一号，所以它默认就安装了 Gboard，而且它一直跟着我到了下一部设备（三星 A42 5G）。但如今市面上销售的大多数安卓设备默认都使用第三方键盘应用。

很高兴看到这项进展。

2 个赞
29

我已经合并了此错误的修复程序：

修复程序已部署到 Meta 和您的站点 @ljpp，请告知我您的用户是否仍然可以重现此问题。

5 个赞