Content Script Isolation: ما الذي يشارك الصفحة وما الذي لا يشاركه

عندما تعمل إضافة داخل موقع، content script تستطيع قراءة وتعديل DOM، لكن متغيرات JavaScript الخاصة بالصفحة ليست بالضرورة في نفس execution world. هذا العزل يقلل التعارض لكنه يربك المطور الذي يتوقع استدعاء function من window مباشرة. الحل هو استخدام DOM أو APIs ورسائل موثقة، واللجوء لحقن page context فقط عندما توجد حاجة واضحة.

افهم Isolated World

الإضافة والصفحة قد تريان نفس DOM لكن لكل منهما global object وسياق JavaScript منفصل. متغير window.foo الذي أنشأته الصفحة قد لا يظهر كما تتوقع، والعكس. لا تحاول كسر العزل بحيل عامة.

استخدم DOM كواجهة بحذر

يمكن قراءة attributes أو text وتعديل nodes، لكن الصفحة نفسها غير موثوقة. أي data-* أو hidden field مجرد input وليس policy. Escape المحتوى عند إدخاله في UI الإضافة.

استخدم Message Passing لل ـBackground

Content script ترسل request محدد إلى service worker بدل الوصول مباشرة لكل APIs. Validate message schema و sender.tab/origin قبل تنفيذ action حساس.

الحقن في Main World استثناء

إذا تحتاج hook إلى API داخل page JS، inject code محدودًا يفعل غرضًا واحدًا ويعيد data منقحة. لا تمرر secrets إلى main world، لأن scripts الصفحة يمكنها رؤيتها.

اختبر مواقع ذات CSP و Frames

Iframe لها origins وسياقات مختلفة. حدد all_frames و match_about_blank فقط عند الحاجة، واختبر nested frames. لا تفترض أن top URL يحدد ثقة كل frame.

نظف Listeners والعناصر

SPA navigation قد تجعل content script تضيف observer أو UI أكثر من مرة. استخدم marker و cleanup عند teardown أو route change. Duplicate observers تسبب memory leak وأفعالًا مكررة.

راجع أقل DOM Access

إذا feature تحتاج زرًا واحدًا، لا تجمع نص الصفحة كلها. تقليل البيانات المقروءة يحسن الخصوصية والأداء ويسهل review.

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

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

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

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

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

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

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

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