MV2 vs MV3: ما الذي يتغير لإضافات المتصفح

الانتقال من MV2 إلى MV3 ليس تغيير رقم manifest فقط. أكبر الفروق تظهر في Background lifecycle، أسلوب اعتراض الشبكة، وسياسات الكود والصلاحيات. لذلك إضافة كانت تعتمد على Background page دائم أو webRequest blocking قد تحتاج إعادة تصميم حقيقية.

Background page تصبح Service Worker

في MV3 الـService Worker يمكن أن يتوقف عندما لا يوجد عمل، لذلك لا تعتمد على متغيرات في الذاكرة كحالة دائمة.

الشبكة والصلاحيات تتغير

declarativeNetRequest يصبح المسار الأساسي لحالات كثيرة كانت تستخدم webRequest blocking، والصلاحيات أكثر تفصيلًا.

الكود البعيد أكثر تقييدًا

MV3 يدفع إلى حزم الكود داخل الإضافة بدل تحميل JavaScript تنفيذي من مصدر خارجي.

اختبر السلوك لا التثبيت فقط

إضافة MV3 قد تثبت وتفتح Popup لكن تفشل في background بعد دقائق. اختبر lifecycle طويلًا.

سيناريو تطبيقي قبل الاعتماد

ابدأ من Request أو API contract قابل لإعادة الإنتاج. ثبّت المدخلات، ثم غيّر عنصرًا واحدًا مثل Header أو Body أو Permission حتى تعرف أثره الحقيقي. في موضوع «MV2 vs MV3: ما الذي يتغير لإضافات المتصفح»، نفّذ تجربة صغيرة قبل تعميم القرار. ابدأ بـ1- راجع permissions.، 2- حدد webRequest usage.، 3- حوّل القواعد الممكنة إلى DNR.، ثم سجل النتيجة قبل توسيع النطاق. لا تحاول تحسين كل شيء في أول Run؛ المطلوب أولًا إنشاء حالة مرجعية تستطيع العودة إليها ومقارنتها. عندما تنجح التجربة، كررها مرة ثانية بنفس الشروط للتأكد أن النتيجة لم تكن صدفة أو أثر Cache أو حالة مؤقتة.

كيف تقيس نجاح التجربة؟

راقب status وduration وheaders والـbody أو schema، وسجل حالات الخطأ بنفس العناية التي تسجل بها النجاح. أدوات المطور الجيدة تجعل الفرق بين تجربتين واضحًا. حوّل النقاط الموجودة في المقال إلى مؤشرات قابلة للرصد: الحالة تحتاج storage عند اللزوم.؛ Timers الطويلة ليست مثل Background page.؛ البدء البارد يجب أن يكون آمنًا.. احتفظ بالقياسات مع timestamp ونسخة التطبيق أو البيئة، لأن مقارنة أرقام من إصدارات أو شروط مختلفة قد تعطي استنتاجًا خاطئًا. وإذا كانت النتيجة رقمية، استخدم أكثر من عينة بدل أفضل أو أسوأ قيمة منفردة.

عند الفشل: ماذا تراجع أولًا؟

إذا فشل الطلب، افصل طبقات المشكلة: DNS/connection، TLS، HTTP، CORS/CSP، authentication، ثم validation. خلط الطبقات يؤدي إلى حلول واسعة وغير آمنة. عند التحقيق استخدم هذه القائمة كحد أدنى: لا remote executable code.؛ CSP متوافقة.؛ host permissions محددة.؛ worker state محفوظة.. سجل ما الذي جربته وما الذي لم يتغير بعد التجربة. هذه المعلومة تمنع الفريق من إعادة نفس المحاولات وتساعد على تحديد ما إذا كان الخطأ في الإعداد أو الأداة أو الشبكة أو بيانات المهمة.

متى تعتمد القرار على نطاق أوسع؟

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