Service Worker في MV3: كيف تتعامل مع التوقف وإعادة التشغيل

الانتقال من background page في MV2 إلى Service Worker في MV3 يغير افتراضًا أساسيًا: الكود الخلفي يمكن أن يُوقف عندما يصبح خاملًا. أي state محفوظة في متغيرات الذاكرة قد تختفي، و timer طويل قد لا يعمل كما يتوقع المطور. الإضافة الموثوقة تعامل كل wake-up كبدء جديد يمكنه إعادة بناء ما يحتاجه من storage أو event context.

لا تعتمد على Global State

متغير يحمل currentProfile أو queue في الذاكرة قد يختفي بين event ين. احفظ state اللازمة في chrome.storage أو IndexedDB وفق الحساسية والحجم، واسترجعها عند handler. لا تحفظ secrets بلا حماية لمجرد سهولة الاسترجاع.

سجل Listeners في Top-level

بعض listeners يجب أن تسجل عند تحميل worker حتى يعرف Chrome الأحداث التي توقظه. تجنب تسجيلها فقط بعد async initialization قد لا يحدث في الوقت المطلوب.

صمم العمليات الطويلة كمراحل

بدل function تنتظر دقائق، قسّم العمل إلى jobs/checkpoints أو استخدم APIs مناسبة مثل alarms. بعد كل مرحلة احفظ progress. إذا توقف worker، event لاحق يستأنف من state.

استخدم chrome.alarms بدل setInterval

Timers JavaScript ليست schedule موثوقة عندما worker نائمة. alarms مصممة لهذا السياق، مع فهم أن التوقيت قد لا يكون real-time دقيقًا تحت power constraints.

اختبر Cold Wake عمدًا

لا تختبر فقط مع DevTools مفتوحة لأنها قد تبقي worker حية. أغلق inspector واتركها تتوقف ثم نفذ event مثل click أو message. تحقق أن initialization و storage load يعملان.

تعامل مع الرسائل المتأخرة

Message sender قد يختفي قبل response. استخدم contracts واضحة ولا تفترض بقاء tab. إذا العمل async طويل، أعد task ID ثم خزّن النتيجة بدل إبقاء port مفتوحًا بلا حد.

راقب أخطاء Lifecycle

سجل startup reason و event type ومدة handler و failures بصورة خفيفة. إذا worker تستيقظ آلاف المرات بلا عمل، راجع listeners أو alarms.

اختبر الإضافة داخل دورة الحياة كاملة

عند التعامل مع «Service Worker في MV3: كيف تتعامل مع التوقف وإعادة التشغيل» لا تكتفِ بتثبيت الإضافة وفتح popup. اختبر التثبيت والترقية وإعادة تشغيل المتصفح وتعليق service worker وإزالته، ثم تأكد من تنظيف listeners والتخزين الذي لم يعد مطلوبًا. شغّل السيناريو داخل بروفايلين للتأكد أن الحالة لا تتسرب بينهما، وجرب رفض permission ثم منحها ثم سحبها. إذا كانت هناك content scripts، راقب توقيت الحقن عند navigation و SPA transitions. بهذه المجموعة تظهر مشاكل لا تراها تجربة يدوية قصيرة بعد التثبيت مباشرة.

معيار القبول قبل الإغلاق

اختبر أثر الترقية وليس التثبيت النظيف فقط. احتفظ ببروفايل على النسخة السابقة ثم حدث الإضافة وراجع storage migrations وال permissions وال background lifecycle. أي warning جديد في console أو extension errors يجب تصنيفه قبل التعميم على كل البروفايلات.

حالة فشل يجب اختبارها

في «Service Worker في MV3: كيف تتعامل مع التوقف وإعادة التشغيل» جرّب صفحة لا تطابق نطاق الإضافة ثم صفحة تطابقه جزئيًا. تأكد أن content script وال ـhost permissions لا تتوسع بسبب wildcard أوسع من الحاجة، وأن تعطيل الإضافة يوقف listeners والرسائل فورًا. هذه الاختبارات تكشف حدود النطاق أكثر من مجرد التأكد أن الميزة تعمل.

توثيق النتيجة للفريق

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