Chrome บอกคุณแล้วว่าทำไม `--load-extension` ถึงใช้ไม่ได้ แต่คุณแค่มองไม่เห็นมัน

มีสองแฟลกที่มักเจอเวลาเอา extension มาทำ automation:

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

วิธีแบบเดิมมักจะสั่ง Puppeteer หรือ Playwright ให้ชี้ไปที่ Chrome ที่ติดตั้งอยู่ แล้วส่งแฟลกสองตัวนี้เข้าไปพร้อมกัน

ตอนทดสอบบน Google Chrome 150 แบบมาตรฐานที่ใช้ที่นี่ ตัวเบราว์เซอร์เปิดขึ้นได้ปกติ ไม่มี error จาก command line แต่ service ของส่วนขยายกลับเมินแฟลกทั้งคู่ไปเลย การเชื่อมต่อของ automation ยังใช้ได้ตามเดิม แต่ extension ไม่โผล่มาให้ใช้งาน และอาการที่ตามมาทีหลังก็คือ selector timeout ใน harness นี้

Chrome จะบันทึกเหตุผลที่ปฏิเสธไว้ในบรรทัดเดียว แต่จะเห็นได้ก็ต่อเมื่อเปิด stderr logging ก่อน

ข้อค้นพบหลักคือการเทียบกันระหว่าง browser build ส่วนในช่วงถัดไปสองตอนเป็นบันทึกจาก harness โดยตรง: ตอนหนึ่งว่าด้วยการดาวน์โหลดที่ถูกทริกจาก extension และอีกตอนว่าด้วยเส้นทางติดตั้งผ่าน command line บนไฟล์ตัวอย่าง file:// Thunderbit เองก็เป็นส่วนขยาย Chrome ดังนั้นประเด็นนี้จึงเกี่ยวข้องกับเราโดยตรง แต่ Thunderbit ไม่ใช่เป้าหมายของการทดสอบครั้งนี้

บรรทัดที่บอกทุกอย่าง

เพิ่ม --enable-logging=stderr แล้วเปิด Chrome แบบมาตรฐานพร้อมแฟลกเหล่านี้:

อ้างอิงทางการ: ซอร์สของ Chrome extension service ใน 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 build ที่มีแบรนด์ตามนั้น จากสิ่งที่เห็นในครั้งนี้ มันยืนยันว่า Google Chrome 150 แบบมาตรฐานเมินแฟลก และชี้ตำแหน่งต้นทางได้ด้วย แต่ยังไม่พอจะพิสูจน์ลำพังว่ารุ่นนั้นไม่เกี่ยวข้อง หรือบอกชัดว่ามีกลไก implementation แยกต่างหาก

ส่วนที่เหลือคือการยืนยันและผลที่ตามมา

ยืนยันด้วยพฤติกรรมจริง

extension MV3 ขนาดเล็กที่สร้างขึ้นเพื่อการทดสอบนี้ ไม่ได้เป็นตัวที่ดาวน์โหลดมาใช้ตรง ๆ มันใช้ content script, popup, การส่งข้อความไปกลับ, การดึงข้อมูลจาก DOM และการส่งออกผ่าน chrome.downloads กับ fixture สินค้า 3 รายการในเครื่อง harness จะบันทึกการตรวจสอบ 6 ขั้นตอนแบบนับเป็นข้อ ๆ ได้แก่: service worker ถูกลงทะเบียน; marker ของ extension มี ID ตรง; content-script marker ตรงกัน; ปุ่มใน popup มองเห็นได้; popup ส่งคืน 3 แถว; CSV ที่จับได้มีแถวที่คาดไว้ครบ นอกจากนี้ยังมีการยืนยันความสอดคล้องแยกต่างหากที่เทียบสัญญาณจาก service worker และ marker บนหน้าเว็บเข้าด้วยกัน

ทั้งสาม browser build ใช้แฟลกส่วนขยายชุดเดียวกัน, ไดเรกทอรีส่วนขยายเดียวกัน, fixture ผ่าน HTTP, โหมด headed persistent-context และโปรไฟล์ใหม่แยกต่อแต่ละรอบ ฝั่ง stock ถูกเรียกผ่าน channel: 'chrome'; ส่วนอีกสองฝั่งที่ผ่านใช้ executablePath แบบระบุชัดเจน สตริงเวอร์ชันอ่านกลับมาผ่าน CDP

สรุปดิบ: Chrome for Testing 149, stock Chrome 150, Chrome for Testing 151, และ คำเตือน stderr.

Chrome for Testing 149 ถูกใส่มาโดยตั้งใจ: มัน เก่ากว่า บิลด์มาตรฐานที่เอามาเทียบกัน ถ้าความสามารถนี้ถูกตัดออกเพราะอัปเวอร์ชัน บิลด์ที่เก่ากว่าน่าจะเป็นตัวที่ยังใช้ได้ และบิลด์ที่ล้มเหลวน่าจะเป็นตัวใหม่ที่สุด แต่ในความจริง บิลด์ที่ล้มเหลวกลับอยู่ตรงกลางระหว่างสองตัวที่ใช้งานได้ ซึ่งตัดสมมติฐานเรื่องการถอดความสามารถแบบไล่ตามเวอร์ชันง่าย ๆ ออกไป

อย่างไรก็ตาม ตารางนี้อย่างเดียวไม่ได้พิสูจน์ว่าตัว gate ขึ้นกับบิลด์ และต้องอธิบายให้ชัดว่าทำไม ช่องที่ล้มเหลวมีแค่ช่องที่เป็น stock และช่องที่เป็น 150 เท่านั้น ดังนั้นในดีไซน์นี้ build กับ version ยังถูกผูกกันแน่นอยู่ สาม arms นี้ใช้ตัดทิ้งได้แค่การ ถอดออกแบบ monotonic; ยังตัดทิ้งไม่ได้ว่า “พังใน 150 แล้วกลับมาใช้ได้ใน 151” การจะได้ข้อสรุปนั้นจากพฤติกรรมล้วน ๆ ต้องมี cell ที่เครื่องนี้สร้างไม่ได้: Chrome for Testing 150 หรือบิลด์แบรนด์ที่เป็นเวอร์ชันอื่น

คำเตือนนี้ช่วยหนุนการตีความว่าเป็นข้อจำกัดของบิลด์แบรนด์ เพราะมันเอ่ยชื่อ Google Chrome ตรง ๆ ขณะที่พฤติกรรมสาม arms ตัดได้แค่การถอดออกแบบแบบเรียบง่ายเท่านั้น ถ้าจะพิสูจน์ว่าเป็นกลไกที่ไม่ขึ้นกับเวอร์ชันจริง ๆ ยังต้องมีการเทียบบิลด์ต่างแบรนด์ในเวอร์ชันเดียวกัน หรือมีหลักฐานจากซอร์ส/คอนฟิกมาช่วย

อาร์ติแฟกต์รายบิลด์ที่ลิงก์ไว้แสดงผลสรุปของแต่ละ arm แต่อาร์ติคนี้ไม่ได้เผยตาราง run-by-run สำหรับจำนวน launch ที่เพิ่มเข้ามา จึงไม่ได้ใช้ตัวนับนั้นเป็นหลักฐานอิสระ

สัญญาณเดียวไม่พอจะบอกว่า “มันไม่ได้โหลด”

เวอร์ชันแรกของการทดสอบนี้ตัดสินว่าส่วนขยายโหลดแล้วหรือยัง โดยดูจาก marker ที่ content script เขียนลงหน้าเว็บ — และนั่นก็เป็นวิธีเดียวกับที่ใช้ตัดสินว่า content script ทำงานหรือไม่ การอ่านค่าเดียว ถูกใช้เป็นสองการวัด ถ้า marker หายไป คุณจะแยกไม่ออกว่า “extension ไม่เคยโหลด” หรือ “โหลดแล้วแต่ content script ไม่ได้ inject” ซึ่งสองกรณีนี้มีวิธีแก้คนละแบบเลย

extension MV3 รัน background service worker และ Playwright เปิดดู service worker ได้โดยตรง นี่คือสัญญาณอิสระ เพราะมันไม่ได้แตะหน้าเว็บ จึงไม่สับสนกับการ inject ตอนนี้การทดสอบอ่านทั้งสองสัญญาณและตรวจว่าตรงกัน

ทั้งสามรอบผลตรงกัน ใน stock Chrome ไม่เคยมี service worker ถูกลงทะเบียนเลย — นี่คือข้อสรุปที่หนักแน่นที่สุด ส่วนใน Chrome for Testing ทั้งสองบิลด์ worker ถูกเปิดขึ้นที่ chrome-extension://<id>/background.js ก่อนที่จะเปิดหน้าเว็บเสียอีก

ใช้ Chrome for Testing ซึ่งคุณอาจมีอยู่แล้ว

สอง arm ที่ผ่านใช้ executable ของ Chrome for Testing ที่ระบุเวอร์ชัน 149.0.7827.55 และ 151.0.7922.10 ชัดเจน ให้ชี้ executablePath ของ Playwright ไปที่ executable ที่ pin ไว้ แทนการให้ resolve stock Chrome ผ่าน channel: 'chrome' ส่วน npx playwright install chromium จะติดตั้ง Chromium ที่ Playwright ดูแลให้ ซึ่งก็มีประโยชน์สำหรับ automation เช่นกัน แต่ไม่ใช่ distribution label เดียวกับ Chrome for Testing ทั้งสอง arm และไม่ได้เป็น arm ที่สี่ในการเปรียบเทียบนี้

อ้างอิงทางการ: ประกาศ Chrome for Testing.

รีวิวที่เกี่ยวข้อง: การตรวจสอบสิทธิ์ของ Chrome extension สำหรับ scraper.

ยังมีข้อดีอีกอย่างที่สำคัญกว่าปัญหานี้เฉพาะหน้า: stock Chrome อัปเดตตัวเองอยู่เบื้องหลัง คุณอาจมีชุดทดสอบที่ผ่านในวันนี้ แต่พอถึงวันอังคารกลับพัง โดยไม่มี commit ไหนอธิบายสาเหตุ Chrome for Testing ถูก pin ไว้แล้ว สำหรับงานที่ผลลัพธ์ต้องยังมีความหมายในอีกสามเดือน เรื่องนี้สำคัญกว่าความสะดวก

หมายเหตุจาก harness: การจับไฟล์ที่ extension ส่งออก

สำหรับ extension ด้าน scraping การส่งออกคือหัวใจ — ตรงนี้แหละที่ฟิลด์มักหาย, encoding เพี้ยน, และข้อมูล nested ถูกแบนผิดรูป สิ่งที่ไม่มีใครบอกไว้ชัดมีอยู่สองอย่าง และทั้งคู่สร้างปัญหาได้

ใน harness MV3/Playwright 1.56.0 นี้ chrome.downloads ไม่ได้ทำให้ Playwright ยิง download event ออกมา เมื่อ extension ส่งออก CSV ผ่าน API นั้น waitForEvent('download') ไม่ยอม resolve การจับไฟล์ทำผ่านการเปิด CDP session, ตั้งค่า download behavior แบบชัดเจน และอ่านผลลัพธ์จาก output directory:

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

ใน harness เดียวกัน เส้นทางจับผ่าน CDP นี้ไม่ได้รักษาชื่อไฟล์ตามที่ขอไว้ ส่วนหัวและทั้งสามแถวรอดครบ แต่ probe-export.csv ถูกบันทึกเป็น download.csv นี่คือพฤติกรรมที่สังเกตได้จาก build และ config ที่ทดสอบ ไม่ใช่กฎตายตัวที่รับประกันได้สำหรับทุกการดาวน์โหลดจาก extension ให้ตรวจเนื้อหาแยกจากชื่อไฟล์

หมายเหตุจาก harness: พฤติกรรม file:// สำหรับเส้นทางติดตั้งนี้

ระหว่างการตรวจส่วนนี้ มีข้ออ้างที่ถูกพูดกันกว้างขวางข้อหนึ่ง ซึ่งสุดท้ายแล้วไม่จริง และเคยหลุดเข้าไปในร่างแรกของบทความนี้ด้วย: content script ไม่ทำงานบนหน้า file:// เพราะ extension ไม่มีสิทธิ์เข้าถึงไฟล์โดยค่าเริ่มต้น

เมื่อวัดบน Chrome for Testing ทั้งสองบิลด์ โดยโหลด extension จาก command line แล้วเปิดตรงไปที่ file:///…/fixture/index.html: content script inject ได้ตามปกติ มี marker อยู่, ID ของ extension ถูกต้อง, ทั้งสองบิลด์เหมือนกัน Command-line-loaded unpacked extensions มี file access อยู่แล้ว; สวิตช์ “grant file access” ที่คนคุ้นกันนั้นใช้กับเส้นทางติดตั้งอีกแบบหนึ่ง

การเสิร์ฟ fixture ผ่าน HTTP ยังเป็นทางเลือกที่ดีกว่า เพราะ file:// page ไม่เหมือน target จริง แต่เหตุผลนี้เป็นเรื่องของความเหมือนจริง ไม่ใช่ข้อกำหนดทางเทคนิค และคำอธิบายที่มักใช้กันเกี่ยวกับมันก็ผิด

สิ่งที่บทความนี้ยังไม่ได้พิสูจน์

• กลไกของ gate ลึกได้เท่าคำเตือนที่แสดงออกมาเท่านั้น Chrome บอกว่าแฟลกเหล่านี้ไม่อนุญาตในบิลด์นี้ และระบุชื่อไฟล์ต้นทาง แต่ไม่ได้อ่านจากซอร์สว่ามันมาจาก build config, policy plumbing หรืออย่างอื่น
• นี่เป็นแค่เครื่องเดียว macOS บน arm64, patch version แบบ stock หนึ่งตัว, และ Chrome for Testing สองบิลด์ Chrome เปลี่ยนเร็วพอที่จะต้องตรวจซ้ำ ไม่ใช่อ้างอิงแบบปักหมุด
• นี่เป็นแค่เส้นทาง --load-extension การติดตั้ง .crx แบบ packed, การโหลดผ่าน developer mode, และ enterprise allowlist policy ไม่ได้ทดสอบ ไม่มีอะไรในนี้ที่รองรับคำกล่าวว่า “stock Chrome รัน extension ไม่ได้”
• extension ที่ใช้เป็น stub ที่สร้างมาเฉพาะงาน มันทดสอบกลไกที่ scraper extension ใช้จริง แต่ extension จริงใหญ่กว่า และอาจล้มเหลวได้ในแบบที่ stub ล้มเหลวไม่ได้

สิ่งที่ฉันเข้าใจผิดระหว่างทาง

ควรพูดให้ตรง ๆ เพราะทั้งสองความผิดพลาดเป็นชนิดที่มักรอด review ไปได้ถ้าผลลัพธ์โดยรวมดูเหมือนใช่

เวอร์ชันแรกของบทความนี้บอกว่าความล้มเหลวนั้นเงียบสนิท ไม่มี log line ใด ๆ และกลไกก็ไม่มีทางรู้ได้ — ใครที่บอกว่ารู้ก็แค่เดาเอา ความจริงคือกลไกอยู่ห่างไปแค่แฟลกเดียว และ Chrome ก็พิมพ์มันเป็น WARNING มาตลอด ที่แท้ “ฉันหาไม่เจอ” ถูกเขียนใหม่เป็น “มันหาที่ไม่ได้”

ความผิดพลาดข้อที่สองคือข้ออ้างเรื่อง file:// ด้านบน: เอามาจากโน้ตและเขียนใส่กลไกที่มั่นใจเกินไปก่อนจะทดสอบ หนึ่งรอบก็ล้มมันลง

แพตเทิร์นเหมือนกันทั้งสองกรณี คือมีข้อความที่ฟังดูน่าเชื่อและไม่มีใครทัก แล้วก็ถูกส่งต่อเพราะรู้สึกว่าไม่จำเป็นต้องตรวจ วิธีแก้ไม่ใช่แค่เขียนให้ระวังขึ้น แต่ต้องตั้งกฎให้สิ่งที่พูดไว้เลย: ข้ออ้างที่โยงกลับไปหา run จริงไม่ได้ จะไม่ถูกส่งขึ้นงาน

คำสั่งที่ใช้ใน harness ภายในเครื่อง

probe เวอร์ชันต่าง ๆ, extension stub, fixture, และสรุปดิบลิงก์ไว้ที่นี่ แต่ยังไม่ใช่ reproducible bundle สาธารณะแบบ standalone แหล่งดาวน์โหลดและ checksum ของ Chrome for Testing 149 และ 151 ที่ใช้จริงไม่ได้ถูกรายงานไว้ในบทความ และ executable path ด้านล่างก็เป็น input ภายในเครื่อง ควรเผย browser source เหล่านั้นพร้อม repository commit ที่คงที่ ก่อนจะนำการเปรียบเทียบเต็มรูปแบบไปเสนอว่า reproducible ได้จริง

รีวิวที่เกี่ยวข้อง: รีวิว Playwright.

cd harness
npm install playwright@1.56.0
npx playwright install chromium      # Chromium ที่ Playwright จัดการให้; ไม่ใช่สอง arm ของ 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

ใช้สคริปต์เดียวกันและแฟลกส่วนขยายชุดเดียวกันกับทั้งสาม arm แต่การ resolve executable ต่างกัน: CHANNEL=chrome สำหรับ stock Chrome และ EXE สำหรับ binary Chrome for Testing ทั้งสองตัว เวอร์ชันในไฟล์ output แต่ละไฟล์อ่านมาจาก browser จริง ไม่ได้เชื่อจาก label

สำหรับบรรทัด warning ไม่ต้องใช้ harness:

"/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 สำหรับดึงข้อมูลเว็บ

ข้อสรุปและข้อควรระวัง

ในเมทริกซ์ที่ทดสอบ stock Google Chrome 150 ปฏิเสธ --disable-extensions-except กับ --load-extension ขณะที่ Chrome for Testing 149 และ 151 โหลดส่วนขยายได้ Chrome บันทึกการปฏิเสธไว้ที่ระดับ WARNING: "--load-extension is not allowed in Google Chrome, ignoring." ถ้อยคำนี้ชี้ไปทางการตีความว่าเป็นกฎของ build brand และการวาง 149 / 150 / 151 เป็นสามช่วงตัดกันก็หักล้างการถอดออกแบบ monotonic แบบง่าย ๆ ได้ แต่ build กับ version ยังแยกจากกันไม่ออก ถ้าไม่มี arm เทียบข้าม build ในเวอร์ชันเดียวกัน หรือหลักฐานจากซอร์ส/คอนฟิก

ถ้าจะทำ harness สำหรับ extension แบบ pin ได้ ควรใช้ browser executable ที่ระบุเวอร์ชันชัดเจน และตรวจทั้ง service worker กับ content-script marker ใน Playwright 1.56.0 setup นี้ การส่งออกของ extension ต้องอาศัยการจับผ่าน CDP ไปยังไดเรกทอรี และชื่อไฟล์ที่ได้ก็เปลี่ยนไปจากที่ขอไว้ ส่วน stub ที่โหลดจาก command line ก็ inject ได้บน fixture file:// ที่ทดสอบแล้ว; เส้นทางติดตั้งแบบอื่นไม่ได้ทดสอบ

ลองใช้ Thunderbit สำหรับดึงข้อมูลเว็บ Get Started Free

คำถามที่พบบ่อย

--load-extension ถูกเอาออกจาก Chrome ไปแล้วหรือ? ไม่ใช่ Chrome for Testing 149.0.7827.55 และ 151.0.7922.10 ยังโหลด MV3 stub แบบ unpacked จากแฟลกนี้ได้ และผ่านการตรวจทั้ง 6 ขั้น Stock Google Chrome 150.0.7871.187 ปฏิเสธมัน และบันทึกว่า "--load-extension is not allowed in Google Chrome, ignoring" ซึ่งสนับสนุนการตีความว่าเป็น gate ของ build brand แต่ยังไม่ถึงขั้นพิสูจน์ การที่พฤติกรรมไม่ใช่การถอดออกแบบ monotonic ชัดเจน ขณะที่ความเป็นไปได้ว่าเป็น regression เฉพาะ Chrome 150 แล้วกลับมาปกติใน 151 ก็ยังสอดคล้องกับดีไซน์สาม arms นี้อยู่

ทำไมฉันไม่เห็น error แล้วจะรู้ได้อย่างไรว่าเป็น “ไม่เคยโหลด” หรือ “โหลดแล้วพังเงียบ ๆ”? คำเตือนไม่ถูกพิมพ์ใน verbosity ค่าเริ่มต้น ให้เปิดด้วย --enable-logging=stderr แล้วมันจะโผล่ทันที; ถ้าไม่เปิด Chrome จะเริ่มได้ปกติ แต่ extension service จะเมินแฟลก และอาการแรกใน harness คือ selector timeout ถ้าจะแยก “ไม่เคยโหลด” ออกจาก “inject ล้มเหลว” ให้ใช้สัญญาณอิสระสองทาง: background service worker ของ MV3 และ marker ของ content script ใน DOM เป้าหมาย บน stock Chrome ที่ทดสอบ ทั้งสองอย่างไม่ปรากฏ ส่วนใน Chrome for Testing ทั้งสอง arm มีครบ

ถ้าอย่างนั้นควรใช้อะไรแทนสำหรับ automation ของ extension? arm ที่ผ่านใช้ Chrome for Testing แบบ pin ผ่าน executablePath ส่วน Chromium ที่ Playwright จัดการให้เองก็เป็น binary สำหรับ automation ที่เป็นไปได้อีกแบบ แต่ไม่ได้เป็น arm ในการทดสอบนี้ และไม่ควรถูกเรียกว่าเป็น distribution เดียวกันโดยไม่ตรวจ executable ที่ resolve ออกมาก่อน

ทำไม waitForEvent('download') ถึงไม่ยอม resolve ตอน extension ส่งออกไฟล์? ใน setup MV3/Playwright 1.56.0 นี้ event ไม่ resolve และไม่มี suggested filename ถูกส่งมา harness เปิด CDP session, เรียก Browser.setDownloadBehavior พร้อมไดเรกทอรีที่กำหนด แล้วอ่านไฟล์จากดิสก์ ในรอบที่ทดสอบ bytes ของ CSV ยังอยู่ครบ แต่ probe-export.csv ถูกบันทึกเป็น download.csv; ยังไม่ได้ทดสอบการผสมผสาน extension กับ browser ที่กว้างกว่านี้

แล้วบทความนี้ไม่ได้บอกอะไร — ทั้งเรื่อง file:// และเรื่อง stock Chrome โดยรวม? มีสองขอบเขตในคนละทิศทางก่อนเลย Content script ทำงานได้ บน file:// สำหรับ extension ที่โหลดจาก command line — ทดสอบแล้วบน Chrome for Testing ทั้งสองบิลด์ โดย script inject ตามปกติและรายงาน extension id ถูกต้อง ดังนั้นคำกล่าวทั่วไปที่บอกว่าไม่ได้ (เพราะ extension ไม่มี file access by default) จึงไม่จริงสำหรับเส้นทางติดตั้งนี้ การเสิร์ฟ fixture ผ่าน HTTP ยังเป็นแนวปฏิบัติที่ดีกว่า เพราะมันใกล้กับ target จริง ไม่ใช่เพราะ file:// บล็อกการ inject ในอีกทิศทางหนึ่ง: ไม่มีอะไรในนี้ที่บอกว่า stock Chrome รัน extension ไม่ได้ เราวัดแค่เส้นทาง command-line ของ --load-extension เท่านั้น การติดตั้งแบบ packed .crx, การโหลดผ่าน developer mode และ enterprise allowlist policy ไม่ได้ทดสอบ และไม่มีการอ้างว่าเป็นอย่างไร Scope คือคู่แฟลกเดียวที่ tutorial ด้าน automation มักบอกให้ใช้