محدد الرموز التعبيرية يتعطل محرر الرسائل في 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.\n\nفي كلتا الحالتين، فإن إعادة تحميل الصفحة وفقدان المحتوى المكتوب هو سلوك سيء يجب علينا إصلاحه.

24

حسنًا، لقد بحثت في هذا الأمر مرة أخرى اليوم وتمكنت من إعادة إنتاجه بعد تبديل لوحة المفاتيح الافتراضية على هاتفي إلى Gboard. تقوم Gboard أحيانًا بتشغيل أحداث keydown و keyup مرتين لضغطة مفتاح واحدة، وإذا حدث ذلك لآخر مفتاح تضغطه قبل تحديد رمز تعبيري من الإكمال التلقائي، فستحصل على تعطل.

لست متأكدًا مما يتسبب في تشغيل Gboard لهذه الأحداث مرتين، ولكنه يبدو أنه يعتمد على ما كتبته وإعدادات Gboard الخاصة بك.

تتسبب الأحداث المزدوجة في تعطل بسبب الطريقة التي تم بها تصميم مكتبة الإكمال التلقائي لدينا. لذا تستمع المكتبة إلى أحداث keydown و keyup، وفي keydown تقوم بمسح اقتراحات الإكمال التلقائي وفي keyup تقدم اقتراحات جديدة بناءً على مصطلح الإكمال التلقائي الجديد.

ومع ذلك، هناك حارس/تحسين صغير لحماية المكتبة من القيام بعمل مكرر عندما لم يتغير المصطلح منذ الاقتراحات السابقة، وهنا تحدث المشكلة. تقوم المجموعة الأولى من أحداث keydown و keyup بمسح الاقتراحات القديمة وتقديم اقتراحات جديدة كما هو متوقع، ولكن المجموعة الثانية الخاطئة ستقوم بمسح الاقتراحات مرة أخرى في keydown ولكنها لن تقدم اقتراحات جديدة في keyup لأن مصطلح الإكمال التلقائي لم يتغير.

الحل “الأقل خداعًا” الوحيد الذي يمكنني التفكير فيه هو إزالة الحارس/التحسين حتى تقدم المكتبة دائمًا اقتراحات جديدة في keyup، ولكني لست متأكدًا مما إذا كان هذا مرغوبًا فيه أو يستحق العناء.

أعلم أننا نريد إعادة كتابة مكتبة الإكمال التلقائي الخاصة بنا في وقت ما (إنها من أقدم الأكواد في قاعدة الأكواد وتحتاج بشدة إلى إعادة كتابة)، لذا ربما يمكن أن تنتظر هذه المشكلة حتى نصل إلى إعادة الكتابة؟

5 إعجابات
25

هل الانهيار عبارة عن “حلقة لا نهائية” من نوع ما؟ هل يمكننا ببساطة تتبع أننا دخلنا في حلقة تغذية راجعة وتنظيف الأمور؟

إعجاب واحد (1)
26

لا، الانهيار يصل إلى متغير فارغ. عندما يتم مسح الاقتراحات، يتم تعيين المتغير autocompleteOptions إلى فارغ ثم عندما تنقر على أحد الاقتراحات المعروضة نتوقع أن يكون autocompleteOptions مصفوفة ولكنه فارغ.

هذا يعطيني فكرة أخرى: ربما يمكننا التحقق مما إذا كان autocompleteOptions فارغًا عند تحديد اقتراح وإذا كان المتغير فارغًا، فهل نعيد جلب الاقتراحات للمصطلح المحدد؟

إعجابَين (2)
27

نعم، يبدو هذا حلاً بديلاً جيدًا.

إعجابَين (2)
28

آه، أشعر بالغباء لعدم الإبلاغ عن هذه التفاصيل. كان هاتفي السابق عبارة عن Android One نظيف، لذا كان يحتوي على Gboard افتراضيًا، وقد تبعني منذ ذلك الحين إلى الجهاز التالي (Sammy A42 5G). ولكن معظم أجهزة Android المباعة اليوم تستخدم تطبيق لوحة مفاتيح تابع لجهة خارجية افتراضيًا.

يسعدني رؤية هذا التقدم.

إعجابَين (2)
29

لقد قمت بدمج الإصلاح الخاص بي لهذه المشكلة:

تم نشر الإصلاح في Meta وفي موقعك @ljpp، أخبرني إذا كان لا يزال بإمكان المستخدمين إعادة إنتاج المشكلة.

5 إعجابات