يخبرك Chrome بسبب تعطل `--load-extension` — لكنك لن تراه بسهولة.

يشيع استخدام هذين الخيارين في أمثلة أتمتة الإضافات:

--disable-extensions-except=/path/to/ext  --load-extension=/path/to/ext

وتشير الشروحات القديمة إلى توجيه Puppeteer أو Playwright نحو نسخة Chrome مثبتة مسبقًا مع تمرير هذين الخيارين.

في إصدار Google Chrome 150 القياسي الذي اختُبر هنا، شغّل المتصفح نفسه من دون خطأ في سطر الأوامر، لكن خدمة الإضافات تجاهلت الخيارين. اتصلت الأتمتة بشكل طبيعي، غير أن الإضافة لم تظهر؛ وظهر العَرَض المتأخر على هيئة انتهاء مهلة محدِّد في هذا الإطار التجريبي.

سجّل Chrome سبب الرفض في سطر واحد، لكن فقط بعد تفعيل تسجيل stderr.

الخلاصة الأساسية هنا هي المقارنة بين بنيات المتصفح. القسمان اللاحقان ملاحظات خاصة بالإطار التجريبي تحديدًا: أحدهما يغطي التنزيلات التي تطلقها الإضافة، والآخر يغطي مسار التثبيت عبر سطر الأوامر على ملفات fixture من نوع file://. وThunderbit نفسه إضافة Chrome، لذلك لدينا اهتمام مباشر بهذه المشكلة؛ مع العلم أن Thunderbit لم يكن هدف الاختبار.

السطر الذي كشف السبب

أضف --enable-logging=stderr وشغّل Chrome القياسي مع هذين الخيارين:

المرجع الرسمي: مصدر خدمة إضافات Chromium.

WARNING:chrome/browser/extensions/extension_service.cc:442]
  --disable-extensions-except is not allowed in Google Chrome, ignoring.

وإذا مرّرت --load-extension وحده، فستظهر له رسالة تحذير خاصة به من سطر آخر في الملف نفسه:

WARNING:chrome/browser/extensions/extension_service.cc:420]
  --load-extension is not allowed in Google Chrome, ignoring.

أما Chrome for Testing، فعند إعطائه الخيارات نفسها، فلا يطبع أيًا منهما.

"غير مسموح به في Google Chrome." هذا التحذير يجعل تفسير الرفض الذي جرى هنا يميل بوضوح إلى أن الأمر مرتبط ببنية مميّزة من المتصفح. وهو يثبت أن نسخة Google Chrome 150 القياسية تجاهلت الخيار، ويحدد موضع الشيفرة التي أصدرت التحذير. لكنه لا يثبت بصورة مستقلة أن الإصدار غير ذي صلة، ولا يكشف عامل التمييز في التنفيذ.

ما يلي كله للتأكيد وبيان النتائج.

التأكيد سلوكيًا

تستخدم إضافة MV3 بسيطة — صُممت لهذا الاختبار بدلًا من تنزيلها — سكربتًا داخل الصفحة، وواجهة popup، وتبادل رسائل ذهابًا وإيابًا، واستخراجًا من DOM، وتصدير chrome.downloads على ملف fixture محلي يحتوي ثلاثة منتجات. ويسجّل الإطار التجريبي ستة فحوص مرقمة: تسجيل عامل الخدمة؛ وجود وسم الإضافة مع المعرّف؛ تطابق وسم سكربت الصفحة؛ ظهور زر الـ popup؛ عودة ثلاثة صفوف من الـ popup؛ واحتواء CSV الملتقط على الصف المتوقع. كما توجد عملية تحقق مستقلة تطابق بين إشارة عامل الخدمة وإشارة وسم الصفحة.

استخدمت ثلاثة إصدارات الخيارات نفسها الخاصة بالإضافة، مع مجلد الإضافة نفسه، وfixture عبر HTTP، ووضع context مستمر بواجهة ظاهرة، وملف تعريف جديد لكل حالة. اعتمدت الحالة القياسية على channel: 'chrome'، بينما استخدمت الحالتان الناجحتان مسارات تنفيذ صريحة. وتمت قراءة سلاسل الإصدارات عبر CDP.

الملخصات الخام: Chrome for Testing 149، وChrome 150 القياسي، وChrome for Testing 151، وتحذيرات stderr.

أُدرج Chrome for Testing 149 عمدًا، لأنه أقدم من البنية القياسية التي نقارنه بها. لو كان قد أُزيلت هذه القدرة بسبب ترقية إصدار، لكان من المفترض أن يكون الإصدار الأقدم في جانب العمل، وأن تكون البنية الفاشلة هي الأحدث. لكن الواقع أن البنية الفاشلة تقع بين نسختين تعملان، ما يستبعد فكرة التدرّج البسيط مع الإصدار.

هذا الجدول وحده لا يثبت أن الحاجز مرتبط بالبنية، ومن المهم أن نكون دقيقين في السبب. فالخانة الفاشلة الوحيدة هي أيضًا الخانة الوحيدة الخاصة بالبنية القياسية، والوحيدة الخاصة بالإصدار 150 — أي إن البنية والإصدار ما زالا متشابكين تمامًا في هذا التصميم. ثلاث حالات تكفي لاستبعاد الإزالة الرتيبة؛ لكنها لا تستبعد احتمال: «تعطّل في 150 ثم أُعيد العمل في 151». ولإثبات ذلك من السلوك وحده نحتاج خانة لا يستطيع هذا الجهاز إنتاجها: Chrome for Testing 150، أو بنية مميّزة من نسخة أخرى.

يعزز التحذير تفسير أن المشكلة مرتبطة بالبنية المميّزة لأنه يذكر Google Chrome صراحة، بينما يثبت السلوك عبر الحالات الثلاث فقط استبعاد الإزالة الرتيبة البسيطة. وما يزال يلزم وجود مقارنة بين بنيتين على الإصدار نفسه، أو مرجع من الشيفرة/التهيئة، لإثبات آلية مستقلة عن الإصدار.

تُظهر الملفات المرتبطة لكل بنية التشغيل المُلخّص لكل حالة؛ ولا ينشر هذا المقال مصفوفة تشغيل تفصيلية لعدد التشغيل الإضافي، لذلك لا يستخدم هذا العدد كدليل مستقل.

إشارة واحدة لا تكفي لتقول "لم تُحمّل"

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

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

وفي الحالات الثلاث كلها، تطابقت الإشارتان. على Chrome القياسي لم يُسجَّل أي عامل خدمة أصلًا — وهي الصيغة الأقوى من الادعاء. أما على نسختَي Chrome for Testing، فقد ظهر العامل على chrome-extension://<id>/background.js قبل فتح الصفحة أصلًا.

استخدم Chrome for Testing، وقد يكون لديك بالفعل

استخدمت الحالتان الناجحتان ملفات تنفيذ Chrome for Testing محددة، وأبلغا بالإصدارين 149.0.7827.55 و151.0.7922.10. وجّه executablePath في Playwright إلى الملف المثبّت والثابت بدلًا من الاعتماد على channel: 'chrome' للوصول إلى Chrome القياسي. يؤدي npx playwright install chromium إلى تثبيت Chromium المدار من Playwright؛ وهذا قد يكون مفيدًا للأتمتة أيضًا، لكنه ليس نفس تصنيف التوزيعة المستخدم في حالتي Chrome for Testing، ولم يكن حالة رابعة في هذه المقارنة.

المرجع الرسمي: إعلان Chrome for Testing.

مراجعة ذات صلة: تدقيق أذونات إضافة Chrome Scraper.

وهناك فائدة جانبية تستمر بعد هذا الخلل بعينه. فـ Chrome القياسي يتحدّث تلقائيًا في الخلفية، لذا قد ينجح اليوم ما يفشل يوم الثلاثاء من دون أن يفسر لك أي commit السبب. أما Chrome for Testing فهو مثبت ومقفل على نسخة. وإذا كان مهمًا أن تظل نتيجة الاختبار ذات معنى بعد ثلاثة أشهر، فهذه النقطة أهم من الراحة.

ملاحظة خاصة بالإطار التجريبي: التقاط تصدير الإضافة

في إضافة مخصّصة للكشط، يكون التصدير هو جوهر العملية — فهو المكان الذي تضيع فيه الحقول، وتختل فيه الترميزات، وتُسطَّح البيانات المتداخلة بشكل خاطئ. وهناك أمران حوله غير موثّقين، وكلاهما يسبب مشاكل.

في هذا الإطار التجريبي MV3/Playwright 1.56.0، لم تُطلق chrome.downloads حدث التنزيل في Playwright. ومع تصدير الإضافة لملف CSV عبر API، لم يُحسم waitForEvent('download'). والتقط الإطار الملف عبر فتح جلسة CDP، وضبط سلوك التنزيل صراحة، ثم قراءة مجلد الخرج:

const cdp = await ctx.newCDPSession(page);
await cdp.send('Browser.setDownloadBehavior', {
  behavior: 'allow', downloadPath: DIR, eventsEnabled: true,
});

وفي الإطار نفسه، لم يحافظ مسار الالتقاط عبر CDP على اسم الملف المطلوب. بقي العنوان وكل الصفوف الثلاثة كما هي، لكن probe-export.csv وصل باسم download.csv. هذا سلوك ملحوظ في البنيات والإعدادات المختبرة، وليس قاعدة موثّقة لكل تنزيلات الإضافات. لذا تحقّق من المحتوى منفصلًا عن اسم الملف.

ملاحظة خاصة بالإطار التجريبي: سلوك file:// في هذا المسار التثبيتي

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

وبالقياس على نسختَي Chrome for Testing، وعند تحميل الإضافة من سطر الأوامر ثم الانتقال مباشرة إلى file:///…/fixture/index.html: تُدرَج سكربتات المحتوى بصورة طبيعية. يظهر الوسم، ويكون معرّف الإضافة صحيحًا، في كلتا النسختين. الإضافات غير المضغوطة المحمّلة من سطر الأوامر تحصل على إذن الوصول إلى الملفات؛ أما مفتاح "منح وصول الملفات" الذي يتذكره الناس فيتعلق بمسار تثبيت مختلف.

يبقى تقديم fixture عبر HTTP هو الخيار الأفضل، لأن صفحة file:// لا تشبه هدفًا حقيقيًا. لكن هذا تبرير واقعي، لا متطلب تقني، والآلية التي تُذكر عادةً لتبريره غير صحيحة.

ما الذي لا يثبته هذا

• آلية الحاجز لا تُقرأ إلا بقدر ما تسمح به رسالة التحذير. يقول Chrome إن هذه الخيارات غير مسموح بها في هذه البنية ويذكر ملف المصدر. لكن ما إذا كان ذلك مدفوعًا بإعدادات البناء أو بمنطق السياسات أو بشيء آخر، فلم نقرأه من المصدر.
• هذا جهاز واحد فقط. macOS على arm64، إصدار patch قياسي واحد، ونسختان من Chrome for Testing. Chrome يتغير بسرعة كافية بحيث يلزم إعادة التحقق بدلًا من الاستشهاد.
• هذا يخص مسار --load-extension فقط. لم نختبر تثبيتات .crx المعبأة، ولا التحميل في وضع المطور، ولا سياسات قائمة السماح المؤسسية. لا شيء هنا يدعم قول إن "Chrome القياسي لا يشغّل الإضافات".
• الإضافة هنا نموذج مُعدّ لغرض الاختبار. هي تختبر الآليات التي تستخدمها كل إضافة كشط تقريبًا، لكن الإضافة الحقيقية أكبر وقد تفشل بطرق لا يفشل بها هذا النموذج.

ما أخطأت فيه أثناء الوصول إلى هنا

من المفيد قوله بوضوح، لأن الخطأين من النوع الذي يمرّ في المراجعة عندما تبدو النتيجة صحيحة.

النسخة الأولى من هذا النص قالت إن الفشل كان صامتًا، وإنه لا يوجد سطر سجل، وإن الآلية غير قابلة للمعرفة — وأن أي شخص يدّعي معرفتها فهو يخمّن. كانت الآلية على بُعد خيار واحد فقط، وكان Chrome يطبعها طوال الوقت على مستوى WARNING. جرى تدوين "لم أستطع العثور عليه" على أنه "لا يمكن العثور عليه".

أما الثانية فهي ادعاء file:// أعلاه: تكرر من الملاحظات وصيغ مع ربطه بآلية واثقة قبل اختباره. وأسقطه تشغيل واحد.

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

الأوامر المستخدمة في الإطار المحلي

تمت الإشارة هنا إلى probe ونموذج الإضافة وfixture والملخصات الخام، لكن هذا ليس بعد حزمة إعادة إنتاج عامة مستقلة بذاتها. لم تُسجل في المقال مصادر تنزيل Chrome for Testing 149 و151 ولا checksums الخاصة بهما، وكانت مسارات التنفيذ أدناه مدخلات محلية. انشر مصادر هذه المتصفحات مع commit ثابت في المستودع قبل تقديم المقارنة كاملة على أنها قابلة لإعادة الإنتاج بشكل مستقل.

مراجعة ذات صلة: تدقيق Playwright.

cd harness
npm install playwright@1.56.0
npx playwright install chromium      # Chromium المدار من Playwright؛ ليس حالتي CfT أدناه
(cd fixture && python3 -m http.server 8731 &)

SP=$(pwd) OUT=cft-149.json   LABEL=cft-149   EXE="<Chrome for Testing 149>" node probe_v2.mjs
SP=$(pwd) OUT=stock-150.json LABEL=stock-150 CHANNEL=chrome                 node probe_v2.mjs
SP=$(pwd) OUT=cft-151.json   LABEL=cft-151   EXE="<Chrome for Testing 151>" node probe_v2.mjs

استُخدم النص نفسه ومعاملات الإضافة الصريحة نفسها في الحالات الثلاث، لكن طريقة حلّ الملف التنفيذي اختلفت: CHANNEL=chrome لنسخة Chrome القياسية، وEXE لملفي Chrome for Testing. الإصدار في كل ملف خرج يُقرأ من المتصفح نفسه بدلًا من الوثوق بالوسم.

أما لسطر التحذير فلا حاجة إلى إطار:

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --user-data-dir=/tmp/p --enable-logging=stderr \
  --load-extension=/path/to/ext about:blank 2>&1 | grep "not allowed"

حتى تاريخ 2026-07-28.

جرّب Thunderbit لاستخراج بيانات الويب

القرار والتنبيهات

في المصفوفة المختبرة، رفض Google Chrome 150 القياسي --disable-extensions-except مع --load-extension, بينما حمّل Chrome for Testing 149 و151 الإضافة. وسجل Chrome الرفض على مستوى WARNING: "--load-extension is not allowed in Google Chrome, ignoring." تدعم الصياغة تفسيرًا مرتبطًا بالبنية المميّزة، كما أن ترتيب الإصدارات الثلاثة ينفي الإزالة الرتيبة البسيطة، لكن البنية والإصدار ما زالا متشابكين ما لم توجد حالة مقارنة بين بنيتين على الإصدار نفسه أو دليل من الشيفرة/التهيئة.

إذا كنت تريد إطارًا ثابتًا لاختبار الإضافات، فاستخدم ملفًا تنفيذيًا للمتصفح محدد الإصدار بوضوح وتحقق من عامل الخدمة ووسم سكربت المحتوى. وفي هذا الإعداد الخاص بـ Playwright 1.56.0، احتاج تصدير الإضافة إلى التقاط عبر CDP للمجلد، ووصل باسم ملف مختلف. كما أن النموذج المحمّل من سطر الأوامر أُدرج أيضًا على fixture file:// المختبر؛ أما مسارات التثبيت الأخرى فلم تُختبر.

جرّب Thunderbit لاستخراج بيانات الويب Get Started Free

الأسئلة الشائعة

هل تمت إزالة --load-extension من Chrome بالكامل؟ لا. فقد حمّل Chrome for Testing 149.0.7827.55 و151.0.7922.10 نموذج MV3 غير المضغوط من هذا الخيار وأكملا الفحوص الستة جميعها. أما Google Chrome 150.0.7871.187 القياسي فرفضه وسجّل "--load-extension is not allowed in Google Chrome, ignoring". هذا يدعم، لكنه لا يثبت، وجود حاجز مرتبط بالبنية المميّزة: فالسلوك ينفي الإزالة الرتيبة البسيطة، بينما يظل احتمال وجود خلل خاص بـ Chrome 150 أُصلح في 151 متوافقًا مع التصميم ذي الحالات الثلاث.

لماذا لا أرى أي خطأ، وكيف أفرّق بين "لم يُحمّل أبدًا" و"حُمّل وفشل بصمت"؟ التحذير لا يظهر في الوضع الافتراضي للتفصيل. شغّل المتصفح مع --enable-logging=stderr وسيظهر فورًا؛ وبدون ذلك يبدأ Chrome بشكل طبيعي لكن خدمة الإضافات تتجاهل الخيارات، وأول عرض في الإطار التجريبي يكون انتهاء مهلة محدّد. وللفصل بين "لم يُحمّل أبدًا" و"حُمّل لكن فشل في الإدراج"، استخدم إشارتين مستقلتين: عامل الخدمة الخلفي في MV3 ووسم سكربت محتوى داخل DOM الهدف. في حالة Chrome القياسي المختبرة لم يظهر أيٌّ منهما؛ وفي نسختي Chrome for Testing ظهرا معًا.

ما الذي يجب أن أستخدمه بدلًا من ذلك لأتمتة الإضافات؟ استخدمت الحالات الناجحة ملفات Chrome for Testing مثبتة ومثبتة الإصدار عبر executablePath. كما أن Chromium المدار من Playwright خيار أتمتة محتمل آخر، لكنه لم يكن حالة ضمن هذا الاختبار، ولا ينبغي وصفه بأنه نفس التوزيعة دون التحقق من الملف التنفيذي الذي تم حله.

لماذا لا يُحسم waitForEvent('download') أبدًا عندما تصدّر الإضافة ملفًا؟ في هذا الإعداد MV3/Playwright 1.56.0 لم يُحسم الحدث، ولم يُعرض اسم ملف مقترح. فتح الإطار جلسة CDP، واستدعى Browser.setDownloadBehavior مع مجلد صريح، ثم قرأ الملف من القرص. في التشغيلات المختبرة بقيت بايتات CSV سليمة، لكن probe-export.csv وصل باسم download.csv؛ أما توليفات الإضافات والمتصفحات الأوسع فلم تُختبر.

ما الذي لا يقوله هذا — عن عناوين file://، وعن Chrome القياسي عمومًا؟ هناك حدان، في اتجاهين متعاكسين. سكربتات المحتوى تعمل بالفعل على عناوين file:// للإضافات المحمّلة من سطر الأوامر — وقد اختُبر ذلك على نسختَي Chrome for Testing، حيث أُدرج السكربت بشكل طبيعي ورُصد معرّف الإضافة على نحو صحيح، لذا فالادعاء الشائع بأنها لا تعمل هناك (بسبب عدم امتلاك الإضافات وصولًا افتراضيًا إلى الملفات) غير صحيح في هذا المسار التثبيتي. وما يزال تقديم fixture عبر HTTP أفضل لأنه يشبه هدفًا حقيقيًا، لا لأن file:// يمنع الإدراج. وفي الاتجاه الآخر: لا شيء هنا يقول إن Chrome القياسي لا يشغّل الإضافات. لقد قيس فقط مسار سطر الأوامر --load-extension. لم نختبر التثبيت عبر .crx المعبأ، ولا التحميل في وضع المطور، ولا سياسات قائمة السماح المؤسسية، ولا يصدر أي ادعاء بشأنها. النطاق هنا هو زوج الخيارات الذي تُوصي به شروحات الأتمتة.