Chrome Menjelaskan Kenapa `--load-extension` Berhenti Berfungsi. Anda Hanya Tidak Melihat Pesannya.

Dua flag ini lumayan sering muncul di contoh otomasi ekstensi:

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

Panduan lama biasanya menyuruh Puppeteer atau Playwright diarahkan ke Chrome yang sudah terpasang, lalu ditambahkan dua flag tersebut.

Pada Google Chrome 150 standar yang diuji di sini, browser memang tetap terbuka tanpa error di command line, tetapi layanan ekstensi mengabaikan kedua flag itu. Koneksi otomasi tetap jalan normal dan ekstensi tidak pernah muncul; efeknya baru terasa belakangan sebagai timeout selector di harness ini.

Chrome sebenarnya mencatat penolakannya dalam satu baris, tetapi hanya setelah logging stderr diaktifkan.

Temuan utamanya terlihat saat membandingkan antar build browser. Dua bagian setelah ini memang khusus catatan harness: yang satu membahas unduhan yang dipicu ekstensi, dan yang satu lagi membahas jalur instalasi command-line ini pada fixture file://. Thunderbit sendiri adalah ekstensi Chrome, jadi kami punya kepentingan langsung pada masalah ini; Thunderbit bukan target pengujiannya.

Baris pesannya

Tambahkan --enable-logging=stderr lalu jalankan Chrome standar dengan flag itu:

Referensi resmi: source Chromium extension service.

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

Kalau hanya memakai --load-extension, Chrome akan mengeluarkan peringatannya sendiri, dari baris lain di file yang sama:

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

Chrome for Testing, dengan flag yang persis sama, tidak menampilkan keduanya.

“Not allowed in Google Chrome.” Peringatan ini membuat aturan untuk build bermerek jadi interpretasi paling masuk akal dari penolakan yang terlihat. Ini menunjukkan bahwa Google Chrome 150 standar memang mengabaikan flag itu dan juga memperlihatkan lokasi sumbernya. Tapi ini belum membuktikan secara mandiri bahwa versi tidak relevan, atau mengungkap pembeda implementasinya.

Bagian di bawah ini adalah konfirmasi dan konsekuensinya.

Memastikan lewat perilaku

Sebuah ekstensi MV3 minimal, dibuat khusus untuk pengujian ini dan bukan hasil unduhan, memakai content script, popup, round trip pesan, ekstraksi DOM, dan ekspor chrome.downloads terhadap fixture lokal berisi tiga produk. Harness mencatat enam pemeriksaan bernomor: service worker terdaftar; marker ekstensi punya ID; marker content script cocok; tombol popup terlihat; popup mengembalikan tiga baris; CSV yang ditangkap berisi baris yang diharapkan. Sebuah assertion terpisah membandingkan sinyal service worker dan marker halaman yang independen.

Tiga build diuji dengan flag ekstensi yang sama, direktori ekstensi yang sama, fixture HTTP, mode headed persistent-context, dan profil baru untuk tiap arm. Arm stock diarahkan lewat channel: 'chrome'; dua arm yang berhasil memakai executablePath eksplisit. String versi dibaca kembali lewat CDP.

Ringkasan mentah: Chrome for Testing 149, Chrome standar 150, Chrome for Testing 151, dan peringatan stderr.

Chrome for Testing 149 sengaja ikut dimasukkan: versinya lebih tua daripada build standar yang sedang dibandingkan. Kalau kemampuan ini hilang karena loncatan versi, maka build yang lebih tua mestinya masih bekerja, sementara build yang gagal adalah yang paling baru. Kenyataannya, build yang gagal justru berada di antara dua build yang bekerja, jadi ini bukan sekadar progresi versi yang lurus.

Tabel ini saja belum membuktikan bahwa gate-nya berbasis build, dan penting untuk menjelaskan alasannya dengan tepat. Satu-satunya sel yang gagal sekaligus adalah satu-satunya sel stock dan satu-satunya sel versi 150 — jadi build dan versi masih saling terkait penuh dalam desain ini. Tiga arm hanya menyingkirkan penghapusan monotonic; mereka belum menyingkirkan kemungkinan “rusak di 150, pulih di 151.” Untuk membuktikannya dari perilaku saja, dibutuhkan sel yang mesin ini tidak bisa hasilkan: Chrome for Testing 150, atau build bermerek pada versi lain.

Peringatan tadi memperkuat interpretasi build bermerek karena secara eksplisit menyebut Google Chrome, sementara perilaku tiga arm hanya menyingkirkan penghapusan monotonic yang sederhana. Tapi untuk membuktikan mekanisme yang tidak bergantung pada versi, tetap diperlukan perbandingan lintas-build pada versi yang sama atau sitasi source/config.

Artefak per build yang terhubung menunjukkan run yang sudah diringkas untuk tiap arm; artikel ini tidak memublikasikan matriks run-per-run untuk jumlah peluncuran tambahan, jadi angka itu tidak dipakai sebagai bukti independen.

Satu sinyal saja tidak cukup untuk bilang “ekstensi tidak ter-load”

Versi awal pengujian ini menentukan apakah ekstensi sudah ter-load dengan melihat marker yang ditulis content script ke halaman — dan itu juga cara ia memutuskan apakah content script sudah berjalan. Satu pembacaan, dipakai untuk dua pengukuran. Kalau marker hilang, kamu tidak bisa membedakan antara “ekstensi memang tidak pernah ter-load” dan “ekstensi ter-load tetapi content script gagal menyuntik,” padahal solusinya sangat berbeda.

Ekstensi MV3 menjalankan background service worker, dan Playwright menampilkannya secara langsung. Itu sinyal independen: ia tidak menyentuh halaman, jadi tidak mungkin tertukar dengan masalah injeksi. Pengujian saat ini membaca keduanya dan memastikan hasilnya konsisten.

Di ketiga run, hasilnya konsisten. Pada Chrome standar tidak pernah ada service worker yang terdaftar — bentuk klaim yang paling kuat. Pada kedua build Chrome for Testing, worker muncul di chrome-extension://<id>/background.js sebelum halaman dibuka.

Gunakan Chrome for Testing, yang mungkin sudah kamu punya

Dua arm yang berhasil memakai executable Chrome for Testing eksplisit dengan versi 149.0.7827.55 dan 151.0.7922.10. Arahkan executablePath Playwright ke executable yang dipin, bukan ke Chrome standar yang dipanggil lewat channel: 'chrome'. npx playwright install chromium memasang build Chromium yang dikelola Playwright; itu juga bisa berguna untuk otomasi, tetapi distribusinya berbeda dari dua arm Chrome for Testing di sini dan bukan arm keempat dalam perbandingan ini.

Referensi resmi: pengumuman Chrome for Testing.

Ulasan terkait: audit permission ekstensi Chrome.

Ada keuntungan tambahan yang bertahan lebih lama dari bug spesifik ini. Chrome standar akan auto-update diam-diam, jadi suite yang lolos hari ini bisa gagal hari Selasa karena alasan yang tidak dijelaskan commit mana pun. Chrome for Testing bersifat pinned. Untuk sesuatu yang hasilnya masih harus masuk akal tiga bulan ke depan, ini lebih penting daripada sekadar praktis.

Catatan harness: menangkap ekspor ekstensi

Untuk ekstensi scraping, ekspor adalah inti segalanya — di situlah field bisa hilang, encoding bisa rusak, dan data bertingkat bisa diratakan dengan salah. Ada dua hal yang tidak terdokumentasi, dan keduanya sama-sama menjebak.

Pada harness MV3/Playwright 1.56.0 ini, chrome.downloads tidak memicu event download milik Playwright. Saat ekstensi mengekspor CSV lewat API, waitForEvent('download') tidak pernah selesai. Harness menangkap file dengan membuka sesi CDP, mengatur perilaku download secara eksplisit, lalu membaca direktori output:

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

Pada harness yang sama, jalur tangkapan CDP ini tidak mempertahankan nama file yang diminta. Header dan ketiga baris tetap utuh, tetapi probe-export.csv tersimpan sebagai download.csv. Ini adalah perilaku yang diamati pada build browser dan konfigurasi yang diuji, bukan invariant yang terdokumentasi untuk setiap download ekstensi. Uji isi secara terpisah dari nama file.

Catatan harness: perilaku file:// untuk jalur instalasi ini

Saat memverifikasi bagian ini, satu klaim yang sangat sering diulang ternyata salah, dan sempat masuk ke draft awal artikel ini: bahwa content script tidak berjalan di halaman file:// karena ekstensi tidak punya akses file secara default.

Berdasarkan pengukuran di kedua build Chrome for Testing, saat ekstensi dimuat dari command line dan langsung diarahkan ke file:///…/fixture/index.html: content script terinjeksi normal. Marker ada, ID ekstensi benar, pada kedua build. Ekstensi unpacked yang dimuat lewat command line memang mendapat akses file; toggle “grant file access” yang sering diingat orang sebenarnya berlaku untuk jalur instalasi lain.

Menayangkan fixture lewat HTTP tetap lebih baik sebagai default, karena halaman file:// sama sekali tidak mirip target nyata. Tapi itu alasan realism, bukan syarat teknis, dan mekanisme yang biasanya dipakai untuk menjelaskannya keliru.

Apa yang tidak dibuktikan di sini

• Implementasi gate ini hanya setebal string peringatannya. Chrome mengatakan flag ini tidak diizinkan di build ini dan menyebut file source-nya. Namun apakah ini didorong oleh config build, plumbing policy, atau hal lain tidak dibaca langsung dari source.
• Ini hanya satu mesin. macOS di arm64, satu patch version stock, dua build Chrome for Testing. Chrome bergerak cukup cepat sehingga ini perlu dicek ulang, bukan cuma dikutip.
• Ini hanya jalur --load-extension. Instalasi .crx yang dibundel, loading mode developer, dan kebijakan allowlist enterprise tidak diuji. Tidak ada yang di sini mendukung pernyataan “Chrome standar tidak bisa menjalankan ekstensi.”
• Ekstensinya adalah stub yang dibuat khusus. Ia menguji mekanik yang dipakai setiap ekstensi scraper, tetapi ekstensi nyata lebih besar dan bisa gagal dengan cara yang tidak bisa ditiru stub.

Apa yang saya salah pahami di sepanjang jalan

Perlu disebutkan dengan jujur, karena dua-duanya adalah jenis kesalahan yang bisa lolos review ketika hasil akhirnya terlihat benar.

Versi pertama tulisan ini mengatakan kegagalannya diam-diam saja, tidak ada baris log, dan mekanismenya tidak bisa diketahui — bahwa siapa pun yang mengaku tahu hanyalah menebak. Ternyata mekanismenya hanya terpaut satu flag, dan Chrome sudah menuliskannya dengan severity WARNING sepanjang waktu. “Saya tidak menemukannya” sempat ditulis menjadi “tidak mungkin ditemukan.”

Yang kedua adalah klaim file:// di atas: berulang dari catatan dan dirangkai dengan mekanisme yang terdengar meyakinkan sebelum benar-benar diuji. Satu run langsung membuktikannya salah.

Polanya sama di kedua kasus. Pernyataan yang terdengar masuk akal dan tidak akan diprotes siapa pun, lalu dibawa terus karena rasanya tidak perlu dicek. Solusinya bukan lebih hati-hati saat menulis, melainkan aturan tentang apa yang boleh dinyatakan: klaim yang tidak bisa ditelusuri ke run tidak boleh lolos.

Perintah yang dipakai di harness lokal

Probe berversi probe, stub ekstensi, fixture, dan ringkasan mentah terhubung di sini, tetapi ini belum merupakan paket reproduksi publik yang benar-benar berdiri sendiri. Sumber unduhan Chrome for Testing 149 dan 151 serta checksum yang tepat tidak dicatat di artikel ini, dan path executable di bawah adalah input lokal. Publikasikan sumber browser itu beserta commit repository yang stabil sebelum menyajikan perbandingan penuh sebagai sesuatu yang benar-benar bisa direproduksi secara independen.

Ulasan terkait: Playwright review.

cd harness
npm install playwright@1.56.0
npx playwright install chromium      # Chromium milik Playwright; bukan dua arm CfT di bawah
(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

Script yang sama dan argumen ekstensi yang eksplisit dipakai untuk ketiga arm, tetapi resolusi executable berbeda: CHANNEL=chrome untuk Chrome standar dan EXE untuk dua binary Chrome for Testing. Versi pada tiap file output dibaca dari browser, bukan dipercaya dari label.

Untuk baris peringatan, harness tidak diperlukan:

"/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"

Per 2026-07-28.

Coba Thunderbit untuk Ekstraksi Data Web

Keputusan dan batasan

Dalam matriks yang diuji, Google Chrome 150 standar menolak --disable-extensions-except plus --load-extension, sementara Chrome for Testing 149 dan 151 berhasil memuat ekstensi. Chrome mencatat penolakannya pada severity WARNING: "--load-extension is not allowed in Google Chrome, ignoring." Pilihan kata itu mendukung interpretasi build bermerek, dan “sandwich” versi menyingkirkan penghapusan monotonic sederhana, tetapi build dan versi masih saling tercampur tanpa arm perbandingan lintas-build pada versi yang sama atau bukti source/config.

Untuk harness ekstensi yang dipin, gunakan executable browser dengan versi yang eksplisit dan verifikasi service worker plus marker content script. Pada setup Playwright 1.56.0 ini, ekspor ekstensi memerlukan tangkapan direktori via CDP dan muncul dengan nama file yang berbeda. Stub yang dimuat dari command line juga terinjeksi pada fixture file:// yang diuji; jalur instalasi lain tidak diuji.

Coba Thunderbit untuk Ekstraksi Data Web Get Started Free

FAQ

Apakah --load-extension dihapus dari Chrome sepenuhnya? Tidak. Chrome for Testing 149.0.7827.55 dan 151.0.7922.10 sama-sama memuat stub MV3 yang tidak dibundel dari flag itu dan menyelesaikan keenam pemeriksaan. Google Chrome 150.0.7871.187 standar menolaknya dan mencatat "--load-extension is not allowed in Google Chrome, ignoring". Ini mendukung, tapi tidak membuktikan, adanya gate untuk build bermerek: perilakunya menyingkirkan penghapusan monotonic sederhana, sedangkan regresi khusus Chrome 150 yang pulih di 151 masih tetap cocok dengan desain tiga arm ini.

Kenapa saya tidak melihat error apa pun, dan bagaimana membedakan “tidak pernah ter-load” dari “ter-load lalu gagal diam-diam”? Peringatan itu tidak muncul pada verbosity default. Jalankan dengan --enable-logging=stderr dan pesannya langsung muncul; tanpa itu Chrome tetap start normal tetapi layanan ekstensi mengabaikan flag, dan gejala pertama di harness adalah timeout selector. Untuk memisahkan “tidak pernah ter-load” dari kegagalan injeksi, pakai dua sinyal independen: background service worker MV3 dan marker content script di DOM target. Pada arm Chrome standar yang diuji, keduanya tidak muncul; pada kedua arm Chrome for Testing, keduanya muncul.

Kalau begitu, apa yang sebaiknya dipakai untuk mengotomasi ekstensi? Arm yang berhasil memakai executable Chrome for Testing yang dipin lewat executablePath. Chromium yang dikelola Playwright juga merupakan binary otomasi yang mungkin dipakai, tetapi ia bukan arm dalam pengujian ini dan tidak boleh dianggap distribusi yang sama tanpa memeriksa executable yang benar-benar dipakai.

Kenapa waitForEvent('download') tidak pernah selesai saat ekstensi mengekspor file? Pada setup MV3/Playwright 1.56.0 ini, event itu tidak selesai dan tidak ada suggested filename yang diberikan. Harness membuka sesi CDP, memanggil Browser.setDownloadBehavior dengan direktori eksplisit, lalu membaca file dari disk. Pada run yang diuji, byte CSV tetap utuh tetapi probe-export.csv sampai sebagai download.csv; kombinasi ekstensi dan browser yang lebih luas tidak diuji.

Apa yang tidak dikatakan di sini — tentang URL file://, dan tentang Chrome standar secara umum? Ada dua batas, ke arah yang berlawanan. Content script memang bekerja di URL file:// untuk ekstensi yang dimuat dari command line — diuji pada kedua build Chrome for Testing, dengan script terinjeksi normal dan ID ekstensi dilaporkan benar, jadi klaim umum bahwa mereka tidak bekerja (karena ekstensi tidak punya akses file secara default) itu salah untuk jalur instalasi ini. Menayangkan fixture lewat HTTP tetap praktik yang lebih baik karena lebih mirip target nyata, bukan karena file:// memblokir injeksi. Sebaliknya: tidak ada di sini yang mengatakan Chrome standar tidak bisa menjalankan ekstensi. Hanya jalur command-line --load-extension yang diukur. Instalasi .crx yang dibundel, loading mode developer, dan kebijakan allowlist enterprise tidak diuji, dan tidak ada klaim tentang itu. Cakupannya hanya pasangan flag yang biasanya disarankan tutorial otomasi.