Bromite: التراجع عن إزالة خيار حظر التشغيل التلقائي من Chrome

عمليات الإزالة في سجل الالتزام:

https://github.com/chromium/chromium/commit/1785f13de1aede35cddacd92f1e462f7f81eff43
https://github.com/chromium/chromium/commit/f286512e7a812a4b666d549208ea6e818a5ab53e

تتعلق هذه الالتزامات بـ "التشغيل التلقائي الصامت" ، وليس التشغيل التلقائي ككل. نحن بحاجة إلى النظر بشكل أعمق في كيف ولماذا تم تغيير ذلك.

ذات صلة: https://www.theregister.com/2020/09/08/google_chrome_autoplay/

عمليات الإزالة في سجل الالتزام:

أعتقد أنه على حق ، التغيير الحقيقي الوحيد هنا ،

https://github.com/chromium/chromium/commit/f286512e7a812a4b666d549208ea6e818a5ab53e#diff -817bdb7b9f231d251a99cdb41048f4b4592efa614697f02b532c88bfc30aa3ed

كل شيء آخر يتعلق بالخيارات (وإحضارها إلى عملية العرض) ، وكذلك للاختبار.
لإعادة تمكين السلوك القديم لجميع المواقع ، يبدو أنه يكفي

return true; // !(IsEligibleForAutoplayMuted();

حاولت ويبدو أن التشغيل التلقائي متوقف (تم اختباره باستخدام youtube وصفحة إعادة التحميل ، ربما يكون الهدف هو حظر جميع مقاطع الفيديو مما يجعل إيماءات المستخدم إلزامية؟).
هل يمكن لشخص ما تقديم بعض حالات الاختبار الأخرى؟

حسنًا ، تشير الالتزامات إلى "التشغيل التلقائي الصامت" ولكنها في الواقع تزيل الوصول إلى جميع إعدادات التشغيل التلقائي.

uazo ما أعتقد أنه يجب علينا استعادته هو أيضًا إعدادات موقع Media التي تحتوي على خيار تمكين / تعطيل التشغيل التلقائي

نعم ، ولكن ربما يتعين علينا انتظار انتهاء إعادة هيكلة كود إعدادات المحتوى (بواسطة فريق الكروم).
في الوقت الحالي أقترح تغيير هذا الخط فقط.

هل لديك رابط مشكلة لإعادة البناء؟ أنا لست على علم.

أنت على حق ، إنها ليست إعادة بناء ديون ، ولكن عودة للعودة! في المرة القادمة أقوم بالبحث قبل كتابة أشياء خاطئة.

https://chromium-review.googlesource.com/c/chromium/src/+/2247730
https://chromium-review.googlesource.com/c/chromium/src/+/2249282
https://chromium-review.googlesource.com/c/chromium/src/+/2240413

إذا وافقت ، سأحاول استعادة هذا الخيار.

https://chromium-review.googlesource.com/c/chromium/src/+/2247730
https://chromium-review.googlesource.com/c/chromium/src/+/2249282
https://chromium-review.googlesource.com/c/chromium/src/+/2240413

يبدو أن هذا بديل لـ PrefServiceBridge ، ولا يبدو أنه تغيير كبير.

إذا وافقت ، سأحاول استعادة هذا الخيار.

يجب أن نعيد إعداد موقع الوسائط لتبديل التشغيل التلقائي ، فهل هذا ما تعنيه؟

يجب أن نعيد إعداد موقع الوسائط لتبديل التشغيل التلقائي ، فهل هذا ما تعنيه؟

نعم ، يمكننا محاولة التراجع عن https://github.com/bromite/bromite/issues/791#issuecomment -719391378

@ uazo نعم ، سيكون ذلك رائعًا

@ csagan5 في أي نقطة من قائمة رقعة البروميت هل تريد التصحيح الجديد؟

uazo يمكنك دائمًا إلحاقها ؛ سأضعهم قبل استبدال المجال الآلي قبل إطلاق سراحهم.

عمليات الإزالة في سجل الالتزام:

أعتقد أنه على حق ، التغيير الحقيقي الوحيد هنا ،

الكروم / الكروم @ f286512 # فرق -817bdb7b9f231d251a99cdb41048f4b4592efa614697f02b532c88bfc30aa3edL313

كل شيء آخر يتعلق بالخيارات (وإحضارها إلى عملية العرض) ، وكذلك للاختبار.

حاولت ويبدو أن التشغيل التلقائي متوقف (تم اختباره باستخدام youtube وصفحة إعادة التحميل ، ربما يكون الهدف هو حظر جميع مقاطع الفيديو مما يجعل إيماءات المستخدم إلزامية؟).

uazo هل من الممكن منع التشغيل التلقائي لمقاطع فيديو تويتر و / أو صور متحركة؟

uazo هل من الممكن منع التشغيل التلقائي لمقاطع فيديو تويتر و / أو صور متحركة؟

BUAWF نقوم باستعادة وظيفة موجودة مسبقًا ، إذا لم يتم حظر صور gif قبل ذلك فلن يتم حظرها الآن

uazo يوجد أيضًا في الكود شيء يسمى UnifiedAutoplayConfig وإعداد kBlockAutoplayEnabled

في الالتزام https://github.com/chromium/chromium/commit/0403932b5ab67de9d2ba2cb8d2f8605acb1a05ed يقول:

يجب علينا أيضًا استخدام سياسة التشغيل التلقائي من WebPreferences.

لذلك هذا مستقل عن الآخر بطريقة ما. وهو يركز أكثر على الصوت. هل يمكنك البحث في UnifiedAutoplayConfig و kBlockAutoplayEnabled لمعرفة ما إذا كان الأمر يستحق تمكينهما أيضًا لنظام Android وتعطيل أي آلة ذكية قد تكون وضعت هناك؟

uazo هل من الممكن منع التشغيل التلقائي لمقاطع فيديو تويتر و / أو صور متحركة؟

BUAWF نقوم باستعادة وظيفة موجودة مسبقًا ، إذا لم يتم حظر صور gif قبل ذلك فلن يتم حظرها الآن

نعم ، لا.
على أي حال ، هل يمكنك تقديم بعض عناوين url للاختبار؟

على أي حال ، هل يمكنك تقديم بعض عناوين url للاختبار؟

https://www.twitter.com/UniverseIce/status/1324993628071108608

يحرر:-
https://www.twitter.com/arter97/status/1325127957497573380

يبدو أن التشغيل التلقائي محظور.

لذلك هذا مستقل عن الآخر بطريقة ما. وهو يركز أكثر على الصوت. هل يمكنك البحث في UnifiedAutoplayConfig و kBlockAutoplayEnabled لمعرفة ما إذا كان الأمر يستحق تمكينهما أيضًا لنظام Android وتعطيل أي آلة ذكية قد تكون وضعت هناك؟

نعم ، يبدو مرتبطًا بسياق الصوت:

Add a toggle to the sound content settings page to toggle
unified autoplay. Also adds a pref to store the user's
preference.

مستخدم هنا:
https://source.chromium.org/chromium/chromium/src/+/master : third_party / blink / Renderer / modules / webaudio / audio_context.cc ؛ l = 468

هنا بعض الشرح (تحذير وحدة التحكم):

 switch (GetAutoplayPolicy()) {
    case AutoplayPolicy::Type::kNoUserGestureRequired:
      NOTREACHED();
      break;
    case AutoplayPolicy::Type::kUserGestureRequired:
      DCHECK(window->GetFrame());
      DCHECK(window->GetFrame()->IsCrossOriginToMainFrame());
      window->AddConsoleMessage(MakeGarbageCollected<ConsoleMessage>(
          mojom::ConsoleMessageSource::kOther,
          mojom::ConsoleMessageLevel::kWarning,
          "The AudioContext was not allowed to start. It must be resumed (or "
          "created) from a user gesture event handler. https://goo.gl/7K7WLu"));
      break;
    case AutoplayPolicy::Type::kDocumentUserActivationRequired:
      window->AddConsoleMessage(MakeGarbageCollected<ConsoleMessage>(
          mojom::ConsoleMessageSource::kOther,
          mojom::ConsoleMessageLevel::kWarning,
          "The AudioContext was not allowed to start. It must be resumed (or "
          "created) after a user gesture on the page. https://goo.gl/7K7WLu"));
      break;
  }

أجرى الاختبار باستخدام https://uazo.github.io/bromite/autoplay.html الخطأ التالي:
DOMException: play() failed because the user didn't interact with the document first. https://goo.gl.qjz9zk/xX8pDD

(المصدر https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/media/autoplay_policy.cc؛l=318)
لذلك ، بشكل افتراضي ، يكون GetAutoplayPolicy() هو AutoplayPolicy::Type::kDocumentUserActivationRequired

يبدو بخير ، أليس كذلك؟

ثابت في 86.0.4240.194 .

يبدو بخير ، أليس كذلك؟

هذا يعتمد. هذا هو التعداد:

  // Different autoplay policy types.
  enum class Type {
    kNoUserGestureRequired = 0,
    // A local user gesture on the element is required.
    kUserGestureRequired,
    // The document needs to have received a user activation or received one
    // before navigating.
    kDocumentUserActivationRequired,
  };

هل kDocumentUserActivationRequired أكثر صرامة من kUserGestureRequired أم أقل صرامة؟ أعتقد أنه أقل صرامة.

أعتقد أنه أقل صرامة.

نعم بالتأكيد. ولكن "يجب أن يتلقى المستند تنشيطًا من قِبل المستخدم" هو نفس السلوك الذي فعلناه مع مقاطع الفيديو التي يتم تشغيلها تلقائيًا (وفي هذه المرحلة يجب أن نفكر في تعديل ذلك أيضًا).
حاليًا أيضًا لا نعرف عدد المواقع التي سنقطعها مع هذا التغيير ، مع الأخذ في الاعتبار أن مقاطع الفيديو تعرض شيئًا ما للمستخدمين (الذين يمكنهم تلقي التنشيط) ، قد لا يحتوي النص الصوتي على واجهة مستخدم.
إذا كانت إعدادات محتويات ، فقد تفكر في الاستثناءات ، ولكن هذا هو تبديل سطر الأوامر وتحويله إلى ذلك سيتطلب العديد من التغييرات.
شخصيا كنت سأنتظر.
بدلاً من ذلك ، سأفكر في تعديل جوهري لإعدادات واجهة المستخدم ، بحيث يتم دمجها وصيانتها بشكل أسرع ، وذلك باستخدام البرمجة الموجهة للكائنات بدلاً من سلسلة if-else من ضباب الوقت (حتى أتمكن من إدراج أخرى ربما تكون أكثر إثارة للاهتمام التغييرات ، مثل التاريخ الانتقائي)

"يجب أن يتلقى المستند تنشيطًا من قِبل المستخدم" هو نفس السلوك الذي فعلناه مع مقاطع الفيديو التي يتم تشغيلها تلقائيًا (وفي هذه المرحلة يجب أن نفكر في تعديل ذلك أيضًا).

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

ما لم أفقد شيئا هنا؟

قد لا يحتوي النص الصوتي على واجهة مستخدم.

ثم لن تلعب. ما هي النسبة المئوية للمواقع التي تحتوي على صوت بدون عناصر تحكم؟ أعتقد أنها أقلية يجب تجاهلها.

هذا هو تبديل سطر الأوامر وتحويله إلى ذلك سيتطلب عدة تغييرات.

من السهل جدًا تحويلها إلى علم ، إذا لم يكن هناك علم بالفعل.

بدلاً من ذلك ، سأفكر في تعديل جوهري لإعدادات واجهة المستخدم ، بحيث يتم دمجها وصيانتها بشكل أسرع ، وذلك باستخدام البرمجة الموجهة للكائنات بدلاً من سلسلة if-else من ضباب الوقت (حتى أتمكن من إدراج أخرى ربما تكون أكثر إثارة للاهتمام التغييرات ، مثل التاريخ الانتقائي)

تتطلب صيانة واجهة المستخدم لإعدادات المحتوى المعاد كتابتها جهدًا كبيرًا بمرور الوقت ، أليس كذلك؟ هل ستلتزم بهذا النوع من الصيانة؟ لا يزال الإصدار الحالي يتطلب صيانة أقل من إعادة الكتابة.

ماذا تقصد بالتاريخ الانتقائي؟ تخزين المحفوظات لمواقع معينة فقط؟ مثير للاهتمام.

تحتاج مقاطع الفيديو في Bromite إلى النقر فوق زر التشغيل.

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

أعتقد أنها أقلية يجب تجاهلها.

وإلا سيعودون كتقارير أخطاء (كما حدث بالفعل)

أشير إلى ما قلته (وأنا أتفق معك) ، إذا كان هناك مستخدم يمكنه الشكوى ، فمن الضروري توقع ذلك.

من السهل جدًا تحويلها إلى علم ، إذا لم يكن هناك علم بالفعل.

قصدت إعداد محتوى ، حتى نتمكن من تنشيط القدرة على استبعاد المواقع المعطلة

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

لا أعلم ، يجب أن نحاول.

هل ستلتزم بهذا النوع من الصيانة؟

بالطبع بكل تأكيد.

لا يزال الإصدار الحالي يتطلب صيانة أقل من إعادة الكتابة.

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

ماذا تقصد بالتاريخ الانتقائي؟ تخزين المحفوظات لمواقع معينة فقط؟ مثير للاهتمام.

نعم ، هذا فقط.

أشير إلى ما قلته (وأنا أتفق معك) ، إذا كان هناك مستخدم يمكنه الشكوى ، فمن الضروري توقع ذلك.

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

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

جرب مع Vimeo وآخرين أيضًا.

سأفتح إصدارًا جديدًا (# 804) نظرًا لأنه تم إصلاح هذا بالفعل.

@ csagan5uazo مشكلتان مع هذا ، أحدهما خطأ والآخر رأي.

حشرة
إعداد موقع "التشغيل التلقائي" العام معطل ولا يمكن التبديل إليه في الإعدادات> إعدادات الموقع> التشغيل التلقائي. أنا قادر فقط على التمكين على أساس كل موقع على حدة. لقطة شاشة من هاتف Pixel 5 يعمل بنظام Android 11: https://neeks.me/cloud/index.php/s/S7iNof4e93da6Np (MP4 كبير جدًا بحيث لا يمكن تحميله هنا)

رأي
بصفتي مطور ويب متكامل متخصص في الواجهة الأمامية UI / UX ، فقد خيبت أملي حقًا لرؤية مقاطع الفيديو الصامتة محظورة افتراضيًا.

خلال السنوات القليلة الماضية ، كان هناك اتجاه متزايد لاستخدام "خلفيات الفيديو". إليك موقع صاحب العمل مع "خلفية فيديو" للرجوع إليها: https://brooklynfoundry.com. من تجربة التصفح ، لا أمانع "خلفيات الفيديو" هذه لأنها تعمل كعنصر تصميم - لكني أكره المواقع (مثل المواقع الإخبارية) التي لديها مشغل ثابت وتحظر الشاشة.

قبل نظام التشغيل iOS 10 ، نادرًا ما يتم استخدام نمط "خلفية الفيديو" هذا عند اكتشاف جهاز محمول. ولكن بمجرد مواءمة سياسات التشغيل التلقائي الخاصة بـ Google و Webkit في عام 2016 ، بدأنا في تنفيذ هذه السياسات أكثر فأكثر. أنا لست معجبًا بهم على الأجهزة التي تستخدم بيانات الجوال فقط (من غير المعقول إضاعة أموال غير محدودة من المستخدمين مقابل "التصميم") ، لكنني لست الشخص الذي يطلق هذه الأنواع من اللقطات.

واحد كونه حشرة

شكرا على الإبلاغ ، لم ألاحظ!

لقد خيبت أملي حقًا عندما رأيت مقاطع الفيديو الصامتة محظورة افتراضيًا

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

لا أرى أنه يختلف عن إذن الوصول إلى الميكروفون ؛ في Bromite ، سنقوم ببساطة بتجاهل "مؤشر مشاركة الوسائط" والسماح للمستخدم باتخاذ القرار صراحة.

شكرا على الإصلاح السريع والردود uazo @ csagan5!

أنا أتفق تماما بشأن اختيار المستخدم كذلك. كان صراختي السابقة نتيجة لإزعاجي من الخطأ ، إذا كان بإمكاني تمكينه بمجرد أن لم أكن لأركز على القيمة الافتراضية.