المشاكل المعروفة عند نقل البيانات إلى إصدار Manifest V3

تتضمّن هذه الصفحة مستندات حول الثغرات في المنصة التي تم حلّها أثناء الانتقال إلى Manifest V3، كما تتضمّن إجابات عن الأسئلة الشائعة حول عملية نقل البيانات.

فروقات الأسعار التي تم حلّها على المنصات

تمت إضافة الإمكانات التالية لمعالجة المشاكل الشائعة التي تعيق عملية نقل البيانات:

  1. إتاحة معالجة الملفات على ChromeOS كبديل عن chrome.fileBrowserHandler (الإصدار 120 من Chrome)
  2. إتاحة النصوص البرمجية للمستخدمين: يمكنك السماح بتسجيل نصوص برمجية للمحتوى تتضمّن رموزًا عشوائية باستخدام userScripts API الجديدة (الإصدار 120 من Chrome).
  3. عمليات إبقاء نشطة إضافية وقوية لمشغّلات الخدمات لبعض العمليات التي تستغرق أكثر من خمس دقائق
    • تمت إضافتها في الإصدار 116 من Chrome على أجهزة permissions.request() وdesktopCapture.chooseDesktopMedia() وidentity.launchWebAuthFlow() وmanagement.uninstall().
    • تمت إضافة هذه الميزة في الإصدار 118 من Chrome لأجهزة chrome.debugger.
  4. زيادة عدد مجموعات القواعد الثابتة والمفعَّلة لـ "طلب الشبكة التعريفية" (DNR) تمت زيادة عدد مجموعات القواعد الثابتة المفعَّلة من 10 إلى 50، وإجمالي عدد مجموعات القواعد الثابتة من 50 إلى 100 (الإصدار 120 من Chrome).
  5. توسيع وظائف المستند خارج الشاشة لتوفير المزيد من الأسباب لاستخدام مستند خارج الشاشة تمت إضافة GEOLOCATION في الإصدار 116 من Chrome.
  6. تحسين التوافق مع واجهة برمجة التطبيقات chrome.tabCapture (الإصدار 116 من Chrome):
    • إتاحة الاتصال بوظيفة getMediaStreamId() من عامل الخدمة
    • إتاحة الحصول على MediaStream من معرّف مصدر بيانات في مستند خارج الشاشة
  7. إطالة مدة بقاء عاملي الخدمة طالما أنّ هناك WebSocket اتصالات نشطة (الإصدار 116 من Chrome)

الأسئلة الشائعة حول Manifest V3

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

  • ستؤدي جميع أحداث الإضافة وطلبات البيانات من واجهة برمجة التطبيقات إلى تمديد فترة بقاء عامل الخدمة.
  • ستبقى برامج الخدمة الخاصة بالإضافات نشطة لفترة أطول من 5 دقائق في بعض حالات الاستخدام المحدّدة، مثل المراسلة الأصلية.

س: هل هناك طريقة للوصول إلى نموذج كائن المستند (DOM) في عاملي الخدمة؟
ج: نتّبع النهج الذي تتّبعه "منصة الويب" بعدم تضمين إذن الوصول إلى نموذج المستند (DOM) في برامج الخلفية على الويب (التي تشمل برامج الخدمة). لدعم حالات الاستخدام التي تتطلّب الوصول إلى DOM في الخلفية من مشغّلي الخدمات، أتحنا إمكانية تفويض العمل في الخلفية إلى مستندات خارج الشاشة قصيرة الأمد توفّر إمكانية الوصول الكامل إلى DOM.

س: هل ستتوفّر طريقة لدعم الرمز البرمجي عن بُعد في الإصدار Manifest V3؟
ج: لتعزيز أمان إضافات Chrome، سنواصل عدم السماح بتنفيذ أي رموز برمجية عشوائية مستضافة عن بُعد في إضافات Chrome. ومع ذلك، هذا لا يعني أنّنا لا نسمح بجميع أنواع تنفيذ الرموز البرمجية الديناميكية. ما زلنا نتيح خيارات مختلفة لتنفيذ الرموز البرمجية بشكل ديناميكي في إضافات Chrome:

س: تعتمد إضافة Manifest V2 على webRequestBlocking غير المتوافق مع Manifest V3. كيف يمكنني مواصلة توفير الوظائف نفسها في الإصدار Manifest V3؟
ج: نحن على ثقة بأنّه يمكن حلّ معظم حالات استخدام حظر الطلبات من خلال واجهة برمجة التطبيقات declarativeNetRequest الجديدة، التي تتضمّن ميزة إضافية تتمثل في تجنُّب الحمل الزائد على الأداء الناتج عن الاتصال بين العمليات، أو تنفيذ الرمز البرمجي في كل طلب، أو الحاجة إلى عملية إضافة نشطة في وقت الطلب. ومع ذلك، لا يزال حظر الطلبات الديناميكي متاحًا لحالات الاستخدام المعقّدة في المؤسسات (أو المؤسسات التعليمية).

هل فاتتنا أي معلومات؟ يُرجى إعلامنا بذلك.