محدد الرموز التعبيرية يتعطل محرر الرسائل في Android / Chrome

هذه المشكلة موجودة منذ بضعة أشهر، ويمكنني تكرارها هنا في Meta باستخدام جهاز Android/Chrome (كلاهما أحدث إصدار) — في الواقع، يحدث هذا منذ عدة أشهر، منذ يناير تقريبًا.

يبدو أن محرر الرسائل “يتعطل” بين الحين والآخر عند اختيار إيموجي مقترح.

خطوات إعادة الإنتاج:

  1. انشر ردًا على موضوع وأضف بعض النص.
  2. ابدأ بإضافة إشارة الإبهام للأعلى عن طريق كتابة “:+1” ثم اضغط على الإيموجي المقترح :+1:

ما يحدث:

يبدو أن المحرر يتعطل بطريقة ما أو يعاد رسمه. عادةً ما يُفقد بعض النص المكتوب.

ليست هذه مشكلة قابلة للتكرار بنسبة 100%، لكن يمكنني الوصول إليها بسهولة خلال دقيقة من التجريب.

إعجابَين (2)

ما الإصدار الدقيق من Android/Chrome الذي تستخدمه؟

يمكنني تكرار المشكلة. إليك تتبع المكدس:

_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

هذه هي السطر:

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

يحدث الخطأ لأن selectedOption تساوي 0 (اقتراح واحد أي الأول) بينما autocompleteOptions هي في الواقع null.

أقوم بالتحقيق في السبب الآن…

لذا، لا أعرف السبب حتى الآن. في البداية، كنت أشك في هذا الطلب المدمج من @Osama:

https://github.com/discourse/discourse/pull/11637

لكنني أضفت العديد من نقاط التوقف المؤقتة ولا يمكنني تحديد “من” يقوم بتعديل autocompleteOptions وتعيينها كـ null.

جعل autocompleteOptions من نطاق الإغلاق الأب من مستويين أعلى أمر غريب أيضًا ويجعل الكود صعب المتابعة والتصحيح.

8 إعجابات

أندرويد 11/كروم 89، أحدث الإصدارات المتاحة.

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

@ljpp / @falco هل ما زلتم قادرين على إعادة إنتاج هذا الخطأ؟ لقد جربت العديد من المتغيرات لإدراج رمز تعبيري ولم أتمكن من إعادة إنتاجه حتى مرة واحدة. إذا كان بإمكانكم إعادة إنتاجه، هل يمكنكم مشاركة الخطوات الدقيقة من فضلكم؟ شكرًا لكم!

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

نعم، لا يزال يحدث تعطل على Chrome لنظام Android بالنسبة لي. يجب عليك اتباع التعليمات بنسبة 100% لتكرار المشكلة، لأنها محددة جدًا.

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

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

تعديل: سأطلب من مجتمعنا ما إذا كان بإمكانهم توفير تغطية اختبار أكثر شمولاً.

تعديل 2: نعم، لقد نجحت في إعادة إنتاج المشكلة بنفسي الآن. يقوم مجتمعنا حاليًا بإجراء الاختبارات، ويبدو أن هناك المزيد من حالات إعادة الإنتاج من قبل المستخدمين العاديين.

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

لقد قمت بتكرار هذا بالخطأ، لذا لا يزال هذا مفتوحًا.

ما زلنا نحتفظ بهذه المشكلة في قائمتنا، لكننا نجد صعوبة بالغة في إعادة إنتاجها وتصحيحها.

لا يمكنني وضع علامة pr-welcome على هذه المشكلة لأنها صعبة للغاية. سنعود إلى هذا الموضوع في وقت لاحق، مع وضع مؤقت لمدة 6 أشهر.

هل لا تزال هذه المشكلة قائمة؟

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

كنت أستطيع تكرار هذه المشكلة بسهولة كبيرة، لكن الآن لا أستطيع تحديد السبب بدقة. إذن المشكلة موجودة، لكنها لا تتكرر بنسبة 100%. سنواصل التجريب ومحاولة اكتشاف ما إذا كانت هناك خطوة معينة في واجهة المستخدم تثير هذه المشكلة.

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

هل يمكنك أن تطلب من شخص قادر على إعادة إنتاج المشكلة أن يتحقق مما إذا كان بإمكانه ذلك على try.discourse.org

لقد قمت بتكراره للتو دون محاولة.

Firefox 94.1.1 (Build #2015842491)

و Chrome 95.0.4638.74

إعجابَين (2)

أشعر أن مُحدِّدات الرموز التعبيرية غير الأصلية للمنصة هي المشكلة الحقيقية هنا. :wink: الحل البديل البسيط هو استخدام مُحدِّد الرموز التعبيرية الأصلي في نظام التشغيل الذي تختاره؟

بالتأكيد هناك حل بديل عادةً. ليس دائمًا، على سبيل المثال قد تكون هناك رموز تعبيرية مخصصة قيد الاستخدام في Discourse.\n\nفي كلتا الحالتين، فإن إعادة تحميل الصفحة وفقدان المحتوى المكتوب هو سلوك سيء يجب علينا إصلاحه.

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

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

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

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

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

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

5 إعجابات

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

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

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

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

إعجابَين (2)

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

إعجابَين (2)

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

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

إعجابَين (2)

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

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

5 إعجابات