ربما منذ التحديث إلى الإصدار المستقر 2.5.0، لا تعمل ملفات الوسائط الصوتية الآمنة على متصفح سفاري عند النقر الأول. يتطلب الأمر نقرتين أو ثلاث نقرات على أيقونة التشغيل لتبدأ الصوت. في النقرات الأولى، لا يُستقبل أي طلب على خادم الويب. يُرسل الطلب فقط مع النقرة الثالثة تقريبًا.
يبدو أن هذه مشكلة متعلقة بالمتصفح لأنها تحدث فقط على سفاري، لكن يبدو مشبوهًا بعض الشيء أن هذا بدأ يحدث حول وقت التحديث إلى 2.5.0.
يمكنني تأكيد أن هذه المشكلة موجودة لدي على iOS باستخدام كل من Safari و Firefox. لا يتم تشغيل الصوت إلا بعد إجراء عدة عمليات تشغيل/إيقاف مؤقت. يبدو مكون الودجة (widget) متطابقًا في كلا المتصفحين (أعتقد أن Firefox على الجوال هو مجرد غلاف حول محرك تصيير Safari للجوال). جربت ذلك على iOS 13.5.1.
يعمل مقطع الصوت هذا من w3schools لدي على كل من Safari و Firefox على iOS: W3Schools Tryit Editor. ربما تكمن المشكلة في أننا نستخدم preload="none"؟ هذا هو الاختلاف الوحيد الذي يمكنني التفكير فيه… أو أن إعادة التوجيه 302 الخاصة بنا لعنوان URL للوسائط الآمن إلى عنوان URL الفعلي للصوت يتسبب في بعض المشاكل؟
بعض الأدلة المحتملة التي جعلتني أعتقد أن المشكلة ناتجة عن إعادة التوجيه:
للأسف، لم أتمكن من ذلك لأنني كنت مشغولاً بمشاريع أخرى. ومع ذلك، فإن هذا الموضوع مدرج في قائمتي، وأتطلع إلى البدء في دراسته بعمق قريباً. كما أننا ناقشنا قضايا مشابهة بشكل موجز داخلياً.
لقد كانت هذه مغامرة حتى الآن.. لقد تمكنت من إعداد تصحيح الأخطاء عن بُعد بين متصفح Chrome على جهاز Ubuntu الخاص بي ومتصفح Safari على iOS في هاتفي iPhone، رغم الكثير من الصعوبات. ومع ذلك، وبشكل مزعج، فإن تبويب الشبكة (Network tab) فارغ، وهو الأهم على الأرجح في هذه الحالة.
لقد اكتشفت أن تعيين preload="metadata" يجعل الصوت يعمل عند النقر الأول في متصفح Safari على iOS، بينما إذا تم تعيينه إلى preload="none"، فإن الأمر يتطلب تسلسلاً من التشغيل > الإيقاف المؤقت > التشغيل مرة أخرى لتشغيل الصوت فعليًا.
لقد جربت ذلك مع video ويبدو أن مشكلة مماثلة موجودة.
تم التغيير إلى preload="none" بسبب تقرير الخطأ الخاص بك هنا Secure media uploads expire. نحن الآن في منطقة غريبة ومزعجة نوعًا ما، لأن إعادة تعيين preload إلى metadata سيعيد إدخال المشكلة المذكورة أعلاه. لقد قمنا مؤخرًا بزيادة مدة صلاحية عناوين URL الموقعة مسبقًا إلى 5 دقائق https://github.com/discourse/discourse/pull/10160، لذا فإن الخطأ الأصلي سيكون أقل مشكلة الآن… لكنه لا يزال مشكلة.
ما زلت أفكر في هذا الأمر وأقوم بتجربة أشياء مختلفة… لست متأكدًا مما إذا كان بإمكاننا الجمع بين أفضل ما في العالمين هنا. إنه ليس تجربة مثالية للوسائط الآمنة التي تتطلب نقرات متعددة لعرضها.
تعديل: لقد نجحت في جعل تبويب الشبكة في أداة التصحيح الخاصة بي يعمل. مثال على مثيل Discourse الداخلي لدينا لوسم audio مع preload="none":
اضغط على التشغيل: GET /secure-media-uploads/dev/original/4X/6/1/8/618a6b19a07de18205cc9889cb604e414b30372b.mp3 والتي تعيد حالة Finished
اضغط على الإيقاف المؤقت.
اضغط على التشغيل مرة أخرى: GET presigned_url_here والتي تعيد حالة 206 Partial Content، ويتم تحميل الصوت بشكل صحيح.
المثير للاهتمام هنا هو أنه مع preload=“metadata” نحصل على نفس تسلسل الطلبات تمامًا، مع نقر تشغيل واحدة فقط. يبدو أن Safari يجلب البيانات الوصفية عند النقر الأول على التشغيل، ثم يحتاج إلى إيقاف مؤقت وتشغيل مرة أخرى لتشغيل الصوت.
لست متأكدًا مما إذا كان هذا يحدث على أجهزة أخرى مثل Android؟ لا أملك جهازًا للتجربة هناك.
ألهمني هذا لإعداد mitmproxy وإعادة النظر فيما يحدث هنا. يبدو أن طلب “تم” الأول لا يغادر جهاز iOS أو متصفح Safari. لا يسجل وكيل mitm أي شيء حتى يتم النقر على PLAY للمرة الثانية.
هل من المنطقي استخدام preload="metadata" فقط لـ Safari (على كل من iOS وسطح المكتب، حيث يمكنني تكرار هذه المشكلة على سطح المكتب أيضًا)، واستخدام preload="none" في الأماكن الأخرى؟
(أيضًا، يبدو أن هذه المشكلة لا تحدث على Android بالنسبة لي، حيث قمت باختبارها في تطبيق ويب تقدمي PWA.)
نعم، أعتقد أننا سنضطر إلى اتباع هذا المسار. شكرًا لك على الاختبار على أندرويد وسفاري سطح المكتب أيضًا. سمة preload معطلة حاليًا، لذا أظن أننا سنحتاج إلى بعض الكود من جانب العميل لاكتشاف أن المتصفح هو سفاري وتبديل سمة preload. سأقوم بإجراء بعض التجارب مع هذا اليوم.
نعم، لكن مع هذا الإصلاح الجديد، أعتقد أنه يمكنني تجاوز هذه المشكلة عن طريق تغيير سمة preload فقط عندما يظهر المنشور الذي يحتوي على الوسائط في مجال الرؤية (على سبيل المثال، عبر التمرير). تكمن المشكلة في أنه بمجرد جلب البيانات الوصفية من عنوان URL للوسائط الآمن، يتم إنشاء عنوان URL موقع مسبقًا واستخدامه في المشغل، وينتهي صلاحيته بعد 5 دقائق. لذا، إذا لم تضغط على التشغيل خلال هذه الـ 5 دقائق، فسوف ينتهي صلاحية العنوان.
أتساءل عما إذا كان بإمكاني استخدام JavaScript لتشغيل الوسائط ثم إيقافها مؤقتًا، وما إذا كان ذلك يحدث فرقًا في طلبات المحتوى الجزئي 206 التي تُرسل لاحقًا، والتي لا تبدو خاضعة لانتهاء صلاحية عنوان URL الموقع المسبق. ومع ذلك، قد أكون مخطئًا هنا، وأحتاج إلى تجربة المزيد.
تعديل: تم التأكيد على جهاز أندرويد باستخدام متصفح Chrome بنفسي أن هذه المشكلة غير موجودة هناك.
بموافقة @martinwoodward، قمت اليوم بعدة تعديلات لتحويل استخدام preload="metadata" لجميع عناصر الصوت والفيديو في جميع السياقات، بما في ذلك الوسائط الآمنة. يجب أن يؤدي هذا إلى حل المشكلة الموضحة هنا.
ملاحظة: إذا بقي المستخدم في الصفحة لأكثر من 5 دقائق، فمن المرجح أنه لن يتمكن من تشغيل الصوت أو الفيديو، لأن عناوين URL الآمنة صالحة حاليًا لمدة 5 دقائق فقط.
