Chrome, `--load-extension`'ın Neden Çalışmadığını Söylüyor. Sadece Siz Göremiyorsunuz.

Extension otomasyonu örneklerinde iki bayrak sıkça kullanılır:

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

Eski yöntemlerde Puppeteer ya da Playwright, sistemde kurulu bir Chrome sürümüne yönlendirilir ve bu iki bayrak birlikte verilir.

Burada test edilen standart Google Chrome 150 derlemesinde tarayıcı komut satırı hatası olmadan açıldı, ancak extension hizmeti iki bayrağı da yok saydı. Otomasyon normal şekilde bağlandı, extension görünmedi; bunun gecikmiş sonucu olarak bu harness içinde bir selector zaman aşımı yaşandı.

Chrome bu reddi tek bir satırda kaydetti, fakat yalnızca stderr günlüğü açıldıktan sonra.

Asıl bulgu, tarayıcı derlemeleri arasındaki karşılaştırmadır. Sonraki iki bölüm özellikle harness notudur: biri extension tetiklemeli indirmeleri, diğeri de file:// fixture’ları üzerindeki bu komut satırı kurulum yolunu ele alır. Thunderbit de bir Chrome extension’ıdır; bu yüzden bu sorun bizim için doğrudan önem taşır. Ancak Thunderbit test hedefi değildi.

Satırın kendisi

--enable-logging=stderr ekleyin ve standart Chrome’u bu bayraklarla başlatın:

Resmî referans: Chromium extension service source.

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

--load-extension bayrağını tek başına verdiğinizde, aynı dosyanın farklı bir satırından gelen ayrı bir uyarı görürsünüz:

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

Chrome for Testing’e aynı bayraklar verildiğinde ise bu uyarıların hiçbiri görünmez.

"Google Chrome’da buna izin verilmiyor." Bu uyarı, gözlenen reddin başlıca yorumunun markalı derleme kuralı olduğunu düşündürüyor. Bu standart Google Chrome 150 derlemesinin bayrağı yok saydığını ve kaynağın konumunu gösteriyor. Ancak bunun sürümün alakasız olduğunu bağımsız biçimde kanıtladığı söylenemez; ayrıca uygulamadaki ayırt edici mekanizmayı da açığa çıkarmaz.

Aşağısı doğrulama ve sonuçlar.

Davranışsal olarak doğrulama

Bu test için sıfırdan oluşturulan minimal bir MV3 extension; content script, popup, mesaj gidip-gelmesi, DOM çıkarımı ve yerel üç ürünlü fixture’a karşı chrome.downloads dışa aktarma işlemini kullanır. Harness altı numaralı kontrolü kaydeder: service worker kayıtlı mı; extension işaretçisi bir ID taşıyor mu; content-script işaretçisi eşleşiyor mu; popup butonu görünür mü; popup üç satır döndürüyor mu; yakalanan CSV beklenen satırı içeriyor mu. Ayrı bir uyum kontrolü de bağımsız service-worker ve sayfa işaretçisi sinyallerini karşılaştırır.

Üç derleme aynı açık extension bayraklarını, aynı extension dizinini, aynı HTTP fixture’ını, headed persistent-context modunu ve her kol için temiz bir profili kullandı. Standart kol channel: 'chrome' üzerinden çözümlendi; geçen iki kol açık executable path kullandı. Sürüm dizeleri CDP üzerinden geri okundu.

Ham özetler: Chrome for Testing 149, standart Chrome 150, Chrome for Testing 151 ve stderr uyarıları.

Chrome for Testing 149 özellikle dahil edildi: karşılaştırıldığı standart derlemden daha eski. Eğer kapasite bir sürüm yükseltmesiyle kaldırılmış olsaydı, çalışan bir eski derlemin çizginin çalışan tarafında, başarısız derlemin ise en yeni tarafta olması beklenirdi. Oysa başarısız derleme iki çalışan sürümün arasında yer alıyor; bu da basit bir sürüm ilerlemesi yorumunu zayıflatıyor.

Yine de o tablo tek başına reddin derlemeye bağlı olduğunu kanıtlamaz; nedenini tam söylemek önemlidir. Başarısız tek hücre aynı anda hem tek standart hücre hem de tek 150 hücresidir; yani bu tasarımda derleme ve sürüm hâlâ tamamen birbirine karışmış durumdadır. Üç kol, tek yönlü kaldırma ihtimalini dışlar; ancak "150’de bozuldu, 151’de düzeldi" senaryosunu dışlayamaz. Bunu davranıştan tek başına çıkarmak için bu makinenin üretemeyeceği bir hücre gerekir: Chrome for Testing 150 ya da başka bir sürümde markalı bir derleme.

Uyarı, Google Chrome adını açıkça verdiği için markalı derleme yorumunu güçlendirir; üç kollu davranış ise yalnızca basit tek yönlü kaldırmayı dışlar. Sürümden bağımsız bir mekanizmayı kanıtlamak için yine de aynı sürümde çapraz derleme karşılaştırması ya da kaynak/yapılandırma atfı gerekir.

Bağlantılı her derleme için özetlenen çalıştırma çıktısı ilgili artefaktlarda gösterilir; bu makale, ek başlatma sayısı için çalıştırma bazlı bir matris yayınlamaz, dolayısıyla o sayıyı bağımsız kanıt olarak kullanmaz.

"Yüklenmedi" demek için tek sinyal yeterli değil

Bu testin ilk sürümü, extension’ın yüklenip yüklenmediğine content script’in sayfaya yazdığı bir işarete bakarak karar veriyordu — content script’in çalışıp çalışmadığına da aynı şekilde bakıyordu. Tek bir okuma, iki farklı ölçüm olarak kullanılmıştı. İşaret yoksa, "extension hiç yüklenmedi" ile "yüklendi ama content script enjekte edilmedi" arasında ayrım yapamazsınız; bu iki durumun çözümü tamamen farklıdır.

MV3 extension’ları bir arka plan service worker’ı çalıştırır ve Playwright service worker’ları doğrudan gösterir. Bu bağımsız bir sinyaldir: sayfaya hiç dokunmaz, dolayısıyla enjeksiyonla karıştırılamaz. Mevcut test ikisini birden okuyor ve birbirleriyle uyumlu olup olmadıklarını kontrol ediyor.

Üç çalıştırmada da birbirleriyle uyumluydular. Standart Chrome’da hiç service worker kayıt edilmedi — iddianın güçlü biçimi budur. Chrome for Testing’in iki derlemesinde ise worker, sayfa açılmadan önce chrome-extension://<id>/background.js adresinde ayağa kalktı.

Zaten elinizde olabilecek Chrome for Testing’i kullanın

Başarılı iki kol, 149.0.7827.55 ve 151.0.7922.10 sürümlerini bildiren Chrome for Testing executable’larını kullandı. Playwright’ın executablePath ayarını, standart Chrome’u channel: 'chrome' üzerinden çözmek yerine sabitlenmiş executable’a yönlendirin. npx playwright install chromium, Playwright tarafından yönetilen bir Chromium derlemesi kurar; bu da otomasyon için kullanışlı olabilir, ancak bu karşılaştırmadaki iki Chrome for Testing koluyla aynı dağıtım etiketi değildir ve dördüncü bir kol olarak kullanılmadı.

Resmî referans: Chrome for Testing announcement.

İlgili inceleme: Chrome extension permissions audit.

Bu arızadan bağımsız, uzun ömürlü bir avantaj da var. Standart Chrome sizin haberiniz olmadan otomatik güncellenir; bu yüzden bugün geçen bir test, yarın herhangi bir commit açıklayamayacağı bir nedenle bozulabilir. Chrome for Testing sabitlenebilir. Sonuçlarının üç ay sonra da anlamlı kalması gereken işler için bu, kolaylıktan daha önemlidir.

Harness notu: extension dışa aktarımını yakalama

Bir scraping extension’ında dışa aktarma her şeydir — alanların kaybolduğu, kodlamaların bozulduğu ve iç içe verilerin yanlış düzleştirildiği yer orasıdır. Bununla ilgili belgelenmemiş iki ayrıntı var ve ikisi de sorun çıkarıyor.

Bu MV3/Playwright 1.56.0 harness’ında chrome.downloads, Playwright’ın download event’ini tetiklemedi. Extension API üzerinden bir CSV dışa aktarırken waitForEvent('download') çözülmedi. Harness, bir CDP oturumu açıp indirme davranışını açıkça ayarlayarak ve çıktı dizinini okuyarak dosyayı yakaladı:

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

Aynı harness içinde, bu CDP yakalama yolu istenen dosya adını korumadı. Başlık ve üç satırın tamamı eksiksiz kaldı, ancak probe-export.csv dosyası download.csv olarak düştü. Bu, test edilen tarayıcı derlemeleri ve yapılandırma için gözlenen bir davranıştır; her extension indirmesi için belgelenmiş bir değişmez kural değildir. İçeriği ve dosya adını ayrı ayrı doğrulayın.

Harness notu: bu kurulum yolunda file:// davranışı

Bu kısmı doğrularken, yaygın biçimde tekrarlanan bir iddianın yanlış olduğu ortaya çıktı ve bu iddia bu makalenin önceki taslağına bile girmişti: content script’ler file:// sayfalarında çalışmaz, çünkü extension’larda varsayılan olarak dosya erişimi yoktur.

İki Chrome for Testing derlemesinde ölçülen sonuç şu oldu: extension komut satırından yüklenip doğrudan file:///…/fixture/index.html adresine gidildiğinde content script normal şekilde enjekte oluyor. İşaret mevcut, extension ID doğru, her iki derlemede de aynı. Komut satırıyla yüklenen unpacked extension’lar dosya erişimine sahiptir; insanların hatırladığı "dosya erişimini ver" anahtarı farklı bir kurulum yoluna aittir.

Fixture’ları HTTP üzerinden sunmak yine de daha iyi varsayımdır, çünkü file:// sayfası gerçek bir hedefe hiç benzemez. Fakat bu, teknik bir zorunluluktan çok gerçekçilik argümanıdır; bunun için genellikle verilen mekanizma da yanlıştır.

Bu çalışmanın kanıtlamadığı şeyler

• Kapının uygulaması, uyarı dizesinin kadar derindir. Chrome bu bayrakların bu derlemede izinli olmadığını söylüyor ve kaynak dosyayı adlandırıyor. Bunun derleme yapılandırması, politika katmanı veya başka bir şey tarafından mı yürütüldüğü kaynak koddan okunmadı.
• Bu yalnızca tek bir makinedir. Arm64 üzerinde macOS, bir standart yama sürümü, iki Chrome for Testing derlemesi. Chrome yeterince hızlı değişiyor; bu nedenle alıntılamak yerine yeniden doğrulamak gerekir.
• Bu yalnızca --load-extension yoludur. Paketli .crx kurulumları, geliştirici modu yüklemesi ve kurumsal allowlist politikaları test edilmedi. Burada hiçbir şey "standart Chrome extension çalıştıramaz" sonucunu desteklemiyor.
• Extension, amaca yönelik bir iskele koddur. Her scraping extension’ının kullandığı mekanikleri test eder; fakat gerçek bir extension daha büyüktür ve bu iskelede görünmeyecek şekillerde başarısız olabilir.

Buraya gelirken neyi yanlış yaptım

Bunu açıkça söylemek gerekiyor; çünkü iki hata da sonuç doğru görünürken incelemeden geçebilecek türden hatalardı.

Bu yazının ilk sürümü, hatanın sessiz olduğunu, hiç log satırı olmadığını ve mekanizmanın bilinemez olduğunu söylüyordu — bunu bilen herkesin tahmin yürüttüğü iddia ediliyordu. Oysa mekanizma tek bir bayrak ötedeydi ve Chrome bunu tüm süre boyunca WARNING seviyesiyle yazıyordu. "Bulamadım" cümlesi, "bulunamaz" diye yazılmıştı.

İkincisi, yukarıdaki file:// iddiasıydı: notlardan alınmış, test edilmeden önce kendinden emin bir mekanizma ile taslağa eklenmişti. Tek bir çalışma bunu yanlışladı.

İki durumda da desen aynıydı. Kimsenin sorgulamayacağı kadar makul görünen bir ifade, kontrol etmeye gerek yok sanılarak ileri taşınmıştı. Çözüm, metinde daha fazla temkin değil; söylenen şeye dair bir kuraldır: Bir çalıştırmayla izlenebilir olmayan iddia yayınlanmaz.

Yerel harness’ta kullanılan komutlar

Sürümlenmiş probe, extension stub, fixture ve ham özetler burada bağlantılıdır; ancak bu henüz bağımsız, herkese açık bir yeniden üretim paketi değildir. Tam karşılaştırmayı bağımsızca yeniden üretilebilir diye sunmadan önce, tam Chrome for Testing 149 ve 151 indirme kaynakları ile checksum’ları makalede yer almıyor ve aşağıdaki executable path’ler yerel girdilerdi. Bu tarayıcı kaynaklarını ve sabit bir repository commit’ini paylaşın, sonra tam karşılaştırmayı yayınlayın.

İlgili inceleme: Playwright review.

cd harness
npm install playwright@1.56.0
npx playwright install chromium      # Playwright Chromium; aşağıdaki iki CfT kolu değil
(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

Aynı script ve aynı açık extension argümanları üç kol için de kullanıldı, ancak executable çözümleme farklıydı: standart Chrome için CHANNEL=chrome, iki Chrome for Testing binary’si için EXE. Her çıktı dosyasındaki sürüm, etiketten güvenilerek değil, tarayıcıdan okunarak alınır.

Uyarı satırı için harness gerekmez:

"/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 itibarıyla.

Web Veri Çıkarma için Thunderbit’i Deneyin

Karar ve uyarılar

Test edilen matriste, standart Google Chrome 150 --disable-extensions-except ile --load-extension birleşimini reddetti; Chrome for Testing 149 ve 151 ise extension’ı yükledi. Chrome bu reddi WARNING seviyesinde kaydetti: "--load-extension is not allowed in Google Chrome, ignoring." Bu ifade markalı derleme yorumunu destekliyor ve sürüm sandviçi basit tek yönlü kaldırmayı dışlıyor; ancak aynı sürümde çapraz derleme kolu veya kaynak/yapılandırma kanıtı olmadan derleme ve sürüm hâlâ birbirine karışık durumda kalıyor.

Sabitlenmiş bir extension harness için, açıkça sürümlenmiş bir tarayıcı executable’ı kullanın ve service worker ile content-script işaretçisini doğrulayın. Bu Playwright 1.56.0 kurulumunda extension dışa aktarımı CDP ile dizin yakalamayı gerektirdi ve farklı bir dosya adıyla geldi. Komut satırıyla yüklenen stub, test edilen file:// fixture’ında da enjekte oldu; diğer kurulum yolları test edilmedi.

Web Veri Çıkarma için Thunderbit’i Deneyin Get Started Free

Sıkça sorulan sorular

--load-extension Chrome’dan tamamen kaldırıldı mı? Hayır. Chrome for Testing 149.0.7827.55 ve 151.0.7922.10, unpacked MV3 stub’ı bu bayrakla yükledi ve altı puanlı kontrolün tamamını geçti. Standart Google Chrome 150.0.7871.187 bunu reddetti ve "--load-extension is not allowed in Google Chrome, ignoring" mesajını kaydetti. Bu, markalı derleme kapısını destekler; ancak kanıtlamaz: davranış basit tek yönlü kaldırmayı dışlar, fakat 151’de düzeltilen Chrome-150’ye özgü bir bozulma üç kollu tasarımla hâlâ uyumludur.

Neden hiçbir hata görmüyorum, ve "hiç yüklenmedi" ile "yüklendi ama sessizce başarısız oldu" nasıl ayırt edilir? Uyarı varsayılan ayrıntı düzeyinde yazdırılmaz. --enable-logging=stderr ile başlatın; hemen görünür. Bu seçenek olmadan Chrome normal açılır ama extension servisi bayrakları yok sayar ve harness’te ilk belirti bir selector zaman aşımı olur. "Hiç yüklenmedi" ile enjeksiyon başarısızlığını ayırmak için iki bağımsız sinyal kullanın: MV3 arka plan service worker’ı ve hedef DOM’daki bir content-script işaretçisi. Test edilen standart Chrome kolunda ikisi de görünmedi; Chrome for Testing’in iki kolunda da ikisi vardı.

Extension otomasyonu için bunun yerine ne kullanmalıyım? Başarılı kollar, executablePath üzerinden sabitlenmiş Chrome for Testing executable’larını kullandı. Playwright tarafından yönetilen Chromium da başka bir otomasyon binary’si olabilir, ancak bu testte bir kol değildi ve çözümlenen executable kontrol edilmeden aynı dağıtım olarak anlatılmamalıdır.

Extension bir dosya dışa aktarınca waitForEvent('download') neden hiç çözülmüyor? Bu MV3/Playwright 1.56.0 kurulumunda event çözülmedi ve önerilen dosya adı da verilmedi. Harness, bir CDP oturumu açtı, Browser.setDownloadBehavior çağırıp açık bir dizin verdi, ardından dosyayı diskten okudu. Test edilen çalıştırmalarda CSV baytları korundu, ancak probe-export.csv dosyası download.csv olarak geldi; daha geniş extension ve tarayıcı kombinasyonları test edilmedi.

Bu neyi söylemiyor — file:// URL’leri hakkında ve genel olarak standart Chrome hakkında? İki sınır, zıt yönlerde. Komut satırından yüklenen extension’lar için content script’ler file:// URL’lerinde çalışır — iki Chrome for Testing derlemesinde test edildi; script normal enjekte oldu ve extension ID doğru raporlandı. Bu yüzden, dosya erişimi varsayılan olarak yok diye onların çalışmadığı yönündeki yaygın iddia bu kurulum yolu için yanlıştır. Fixture’ları HTTP üzerinden sunmak yine de daha iyi pratiktir; çünkü gerçek bir hedefe benzer, file:// enjeksiyonu engellediği için değil. Diğer yönde ise: bunların hiçbiri standart Chrome’un extension çalıştıramadığını söylemez. Yalnızca --load-extension komut satırı yolu ölçüldü. Paketli .crx kurulumu, geliştirici modu yüklemesi ve kurumsal allowlist politikaları ölçülmedi; onlar hakkında hiçbir iddia yoktur. Kapsam, otomasyon rehberlerinin kullanmanızı söylediği o tek bayrak çiftidir.