شكراً لك على تحديد ذلك يا @Moin. لقد قمت بنشر إصلاح:
6 إعجابات
هل ترى أي خطأ في وحدة تحكم المتصفح؟
لقد ذكرت هذه المشكلة في الموضوع الآخر.
إعجاب واحد (1)
تم دمج طلب السحب الآن؛ شكرًا لك يا كيغان!
3 إعجابات
هل واجه مستخدمو هذا المكون هذا الخطأ بشكل أكبر مؤخرًا؟
لقد قمت بتثبيته للتو، إليك فكرة:
انقر على زر النسخ في منشورات متعددة “لبناء” الحافظة الخاصة بك. بهذه الطريقة يمكنك نسخ جزء كامل من سلسلة محادثة بسرعة وبشكل انتقائي.
لنفترض أن هناك خمسة منشورات:
المنشور أ
المنشور ب
المنشور ج
المنشور د
المنشور هـ
تقوم بنسخ د، ثم ب، ثم هـ. ما هو موجود في الحافظة الخاصة بك هو في الواقع:
ب
د
هـ
لذلك يتم ترتيب الحافظة بناءً على تسلسلها الزمني في المحادثة، وليس الترتيب الذي تنسخها به.
واجهتُ خطأً في هذا الأمر، وبما أنه خطأ في JavaScript على جانب العميل، فلا يمكنني العثور عليه في \logs. إصدار Discourse الخاص بي هو 2026.7.0-latest +188
قمت بالبحث في الأمر بشكل أعمق مقابل إصدار Discourse الدقيق الذي لاحظت فيه المشكلة لأول مرة، وكذلك مقابل فرع main الحالي.
في إعداد تاريخي مُعاد بناؤه لشهر يوليو، تمكنت من إعادة إنتاج فشل متعلق بحافظة النسخ (Clipboard): حيث يمكن أن يظهر إشعار النجاح/العلامة التعريفية عند استخدام «نسخ المنشور» (Copy Post) بينما لا يتم استبدال محتوى الحافظة فعليًا. لا أستطيع تأكيد أن هذا كان نفس الخطأ الجذري الذي ظهر في لقطة الشاشة الأصلية لشهر يوليو المتعلقة بخطأ القالب/المكوّن.
ومع ذلك، فإن نفس تنفيذ «نسخ المنشور» يعمل الآن على نسختي الإنتاجية الحالية، بما في ذلك في PWA على iOS Safari.
قمت بمقارنة الكود ذي الصلة بين إصدار Discourse لشهر يوليو وفرع main الحالي. لم يتغير تنفيذ الحافظة الخاص بـ «نسخ المنشور» نفسه، ولم أجد أي تغيير ذي صلة في:
clipboardCopy/clipboardCopyAsync- إرسال إجراءات
DButton، بما في ذلك مسار iOS - محاكاة
DButtonالقديمة (legacy shim) - مسار محوّل قائمة المنشور (post-menu transformer path)
- مسار GET في
discourse/lib/ajax
كما قمت بكتابة مواصفة نظام تجريبية (system spec) توقف طلب المنشور الخام (raw-post request) وتحقق مما إذا كان navigator.clipboard.write() قد بدأ قبل اكتمال الطلب. تنجح هذه الاختبار إذا تم تغيير «نسخ المنشور» لاستخدام clipboardCopyAsync، وتفشل ضد التنفيذ الحالي.
ومع ذلك، فإن «نسخ المنشور» الحالي يعمل في المتصفحات/الأجهزة التي اختبرتها، بما في ذلك iOS Safari PWA، لذا يبدو أن هذا الاختبار يفرض قيد تنفيذ أقوى بدلاً من إظهار تراجع (regression) واجهة مستخدم حالي.
لذلك، لا أقترح حاليًا هذا الاختبار أو تغيير clipboardCopyAsync كحل. قد يكون الفشل التاريخي معتمدًا على سلوك المتصفح/WebKit بدلاً من تغيير في مكوّن «نسخ المنشور» نفسه.
إعجاب واحد (1)
كمتابعة لهذا الموضوع، قمت بفتح طلب سحب (PR) صغير يغيّر مؤشر النجاح/التحقق بحيث لا يظهر إلا بعد اكتمال الكتابة في الحافظة بنجاح، مع مواصفة نظام للتراجع (regression system spec):
حاليًا، ينتظر سير عمل GitHub Actions موافقة المشرفين قبل أن تتمكن مهام CI من التشغيل.
إعجاب واحد (1)