Chrome vám řekne, proč `--load-extension` přestalo fungovat. Jen ten důvod není na první pohled vidět.

Dva přepínače se v ukázkách pro automatizaci rozšíření pořád dokola opakují:

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

Starší návody posílají Puppeteer nebo Playwright na nainstalovaný Chrome a předávají oba přepínače.

V běžném sestavení Google Chrome 150, které jsme tady testovali, se prohlížeč na příkazové řádce spustil bez chyby, ale služba rozšíření oba přepínače ignorovala. Automatizace se připojila normálně a rozšíření nikde nebylo; později se to v tomhle testovacím harnessu projevilo jako timeout selektoru.

Chrome ten důvod odmítnutí zapsal do jednoho řádku, ale až ve chvíli, kdy bylo zapnuté logování na stderr.

Hlavní zjištění plyne z porovnání jednotlivých sestavení prohlížeče. Dvě následující části jsou výslovně poznámky k harnessu: jedna řeší stahování vyvolané rozšířením a druhá tuhle instalační cestu z příkazové řádky na file:// testovacích datech. Thunderbit je samo rozšíření do Chrome, takže na tomhle problému máme přímý zájem; Thunderbit nebyl cílovým testem.

Ten řádek

Přidejte --enable-logging=stderr a spusťte běžný Chrome s těmito přepínači:

Oficiální reference: zdroj k extension service v Chromium.

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

Když předáte jen --load-extension, dostanete jeho vlastní varování, z jiného řádku stejného souboru:

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

Chrome for Testing se stejnými přepínači nevypíše nic.

„Není to v Google Chrome povolené.“ To varování dost silně naznačuje, že důvod odmítnutí je pravidlo pro brandované sestavení. Dokazuje, že tenhle běžný build Google Chrome 150 přepínač ignoroval, a ukazuje i přesné místo ve zdrojáku. Neprokazuje samo o sobě, že je verze nepodstatná, ani neříká, podle čeho se implementace rozhoduje.

Všechno níže už je potvrzení a důsledky.

Potvrzení přes chování

Minimální MV3 rozšíření, vytvořené speciálně pro tenhle test a ne stažené odnikud, používá content script, popup, round-trip zprávu, extrakci DOM a export přes chrome.downloads proti lokálnímu fixture se třemi produkty. Harness sleduje šest očíslovaných kontrol: zaregistrovaný service worker; marker rozšíření s ID; shodný marker content scriptu; viditelné tlačítko v popupu; popup vrátí tři řádky; zachycené CSV obsahuje očekávaný řádek. Samostatná kontrola shody porovnává nezávislé signály ze service workeru a markeru na stránce.

Tři buildy používaly stejné explicitní přepínače pro rozšíření, stejný adresář rozšíření, HTTP fixture, headed persistent-context režim a pro každý běh čerstvý profil. Stock větev se řešila přes channel: 'chrome'; dvě úspěšné větve používaly explicitní cestu k executable. Řetězce verzí se četly zpět přes CDP.

Hrubá shrnutí: Chrome for Testing 149, běžný Chrome 150, Chrome for Testing 151 a stderr warningy.

Chrome for Testing 149 je zařazen schválně: je starší než běžné sestavení, se kterým se porovnává. Kdyby schopnost zmizela s vyšší verzí, starší build by měl být na funkční straně a nefunkční build by byl ten nejnovější. Jenže tady je nefunkční build mezi dvěma funkčními, což vylučuje jednoduchý postupný úbytek funkčnosti.

Ta tabulka sama o sobě ale neprokazuje, že je brána vázaná na build, a je fér říct proč přesně. Jediná neúspěšná buňka je zároveň jediná stock buňka a jediná buňka s verzí 150 — build i verze jsou v tomhle designu pořád dokonale provázané. Tři větve vylučují monotónní odstranění; nevylučují ale scénář „spadlo to v 150 a v 151 se to zase vrátilo“. K tomu by bylo potřeba něco, co tenhle stroj neumí dodat: Chrome for Testing 150, nebo brandovaný build v jiné verzi.

Varování posiluje interpretaci s brandovaným buildem, protože explicitně jmenuje Google Chrome, zatímco třívětvové chování vylučuje jen prostý monotónní úbytek. Aby bylo možné dokázat mechanismus nezávislý na verzi, bylo by stejně potřeba srovnání buildů se stejnou verzí nebo citace ze zdrojáku/konfigurace.

Propojené artefakty po jednotlivých buildech ukazují souhrn běhu pro každou větev; článek ale nezveřejňuje matici běh po běhu pro dodatečný počet spuštění, takže tenhle počet nepoužívá jako nezávislý důkaz.

Jeden signál nestačí k tvrzení „nenačetlo se to“

První verze testu rozhodovala o tom, jestli se rozšíření načetlo, podle markeru, který content script zapisuje do stránky — a stejně tak podle něj určovala, jestli content script běžel. Jeden záznam, použitý jako dvě měření. Když marker chybí, nejde poznat, jestli se „rozšíření vůbec nenačetlo“, nebo jestli „se načetlo, ale content script se nevložil“, a to jsou dvě úplně jiné opravy.

MV3 rozšíření běží přes background service worker a Playwright service workery umí číst přímo. To je nezávislý signál: nesahá na stránku, takže se nemůže splést s injektováním. Současný test čte oba a ověřuje, že se shodují.

Ve všech třech bězích se shodují. Na běžném Chrome se nikdy neregistroval žádný service worker — to je nejsilnější verze tvrzení. Na obou Chrome for Testing se worker objevil na chrome-extension://<id>/background.js ještě před otevřením stránky.

Použijte Chrome for Testing, který už možná máte

Dvě úspěšné větve používaly explicitní Chrome for Testing executable s verzemi 149.0.7827.55 a 151.0.7922.10. V Playwrightu nastavte executablePath na připnuté executable místo toho, abyste nechali stock Chrome dohledávat přes channel: 'chrome'. npx playwright install chromium nainstaluje Chromium spravované Playwrightem; i to může být pro automatizaci užitečné, ale není to stejný distribuční štítek jako dvě větve Chrome for Testing a v tomhle porovnání nešlo o čtvrtou větev.

Oficiální reference: oznámení Chrome for Testing.

Související rozbor: audit oprávnění Chrome scraper rozšíření.

Je tu i vedlejší výhoda, která přežije i tenhle konkrétní problém. Stock Chrome se automaticky aktualizuje pod rukama, takže sada, která dnes projde, může v úterý selhat z důvodu, který neodpovídá žádnému commitu. Chrome for Testing je připnutý. U čehokoli, jehož výsledek má dávat smysl i za tři měsíce, je to důležitější než pohodlí.

Poznámka k harnessu: zachycení exportu rozšíření

U scrapingového rozšíření je export vlastně to hlavní — právě tam se ztrácejí pole, rozbíjí se kódování a špatně se plochují vnořená data. Jsou kolem něj dvě nezdokumentované věci a obě umí potrápit.

V tomhle MV3/Playwright 1.56.0 harnessu chrome.downloads nespustil download event v Playwrightu. Když rozšíření exportovalo CSV přes API, waitForEvent('download') se nikdy nevrátilo. Harness soubor zachytil tak, že otevřel CDP session, explicitně nastavil download behavior a pak přečetl výstupní adresář:

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

Ve stejném harnessu tahle cesta přes CDP nezachovala požadovaný název souboru. Hlavička i všechny tři řádky zůstaly beze změny, ale probe-export.csv skončil jako download.csv. To je pozorované chování u testovaných buildů a konfigurace, ne dokumentovaná invariantní vlastnost všech downloadů z rozšíření. Kontrolujte obsah odděleně od názvu souboru.

Poznámka k harnessu: chování file:// pro tuhle instalační cestu

Při ověřování téhle části se ukázalo, že jedno hodně rozšířené tvrzení je nepravdivé, a dokonce se dostalo i do dřívější verze tohohle článku: že content scripts na file:// stránkách neběží, protože rozšíření nemají defaultně přístup k souborům.

Na obou Chrome for Testing buildích se po načtení rozšíření z příkazové řádky a přímém otevření file:///…/fixture/index.html ukázalo toto: content script se normálně injektuje. Marker je přítomný, ID rozšíření sedí, oba buildy. Command-line načtená unpacked rozšíření mají přístup k souborům; přepínač „povolit přístup k souborům“, který si lidé pamatují, se týká jiné instalační cesty.

Servírovat fixture přes HTTP je pořád lepší výchozí volba, protože file:// stránka není nic jako reálný cíl. Ale je to argument pro realističnost, ne technická nutnost — a běžně uváděné vysvětlení je špatně.

Co z toho neplyne

• Implementace brány je čitelná jen do té míry, do jaké sahá text varování. Chrome říká, že tyhle přepínače v tomhle buildu nejsou povolené, a jmenuje zdrojový soubor. Z toho samotného ale neplyne, jestli je důvod build config, policy plumbing, nebo něco jiného.
• Týká se to jen jednoho stroje. macOS na arm64, jedna stock patch verze, dva Chrome for Testing buildy. Chrome se mění dost rychle na to, aby bylo potřeba to znovu ověřit místo citování.
• Jde jen o cestu --load-extension. Instalace z balíčku .crx, načtení přes developer mode ani enterprise allowlist policy se netestovaly. Nic tady nepodporuje tvrzení „stock Chrome neumí spouštět rozšíření“.
• Rozšíření je účelový stub. Testuje mechaniku, kterou používá každé scraper rozšíření, ale reálné rozšíření je větší a může selhat způsoby, které stub nikdy neukáže.

Co jsem cestou tvrdil špatně

Stojí za to to říct na rovinu, protože obě chyby jsou přesně ten typ, který projde review, když výsledek vypadá správně.

První verze tohohle textu tvrdila, že selhání je tiché, že žádný log neexistuje a že mechanismus nelze poznat — že každý, kdo tvrdí opak, jen hádá. Mechanismus byl přitom o jeden přepínač vedle a Chrome ho celou dobu vypisoval na úrovni WARNING. „Nenašel jsem to“ bylo přepsané jako „nejde to najít“.

Druhá byla ta tvrzení o file:// výše: opsaná z poznámek a napsaná s jistým mechanismem ještě před testem. Jeden běh ji vyvrátil.

V obou případech je vzorec stejný. Zní to rozumně, nikdo se neozve, a dál to putuje, protože ověřování se zdá zbytečné. Oprava není větší opatrnost v textu, ale pravidlo pro to, co se vůbec smí tvrdit: tvrzení, které nejde vystopovat k běhu testu, se nezveřejňuje.

Použité příkazy v lokálním harnessu

Verzované probe, stub rozšíření, fixture i hrubá shrnutí jsou tu odkázané, ale zatím to není samostatný veřejný balíček pro reprodukci. Přesné zdroje downloadů Chrome for Testing 149 a 151 ani jejich checksumy nejsou v článku zaznamenané a cesty k executable níže byly lokální vstupy. Než se celé srovnání vydá jako nezávisle reprodukovatelné, je potřeba zveřejnit tyto zdroje prohlížeče i stabilní commit repozitáře.

Související rozbor: Playwright review.

cd harness
npm install playwright@1.56.0
npx playwright install chromium      # Chromium spravované Playwrightem; ne dvě CfT větve níže
(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

Stejný skript i stejné explicitní argumenty pro rozšíření se použily pro všechny tři větve, ale lišilo se získávání executable: CHANNEL=chrome pro stock Chrome a EXE pro dvě binárky Chrome for Testing. Verze v každém výstupním souboru se čte z prohlížeče, nebere se z popisku.

Pro varovný řádek není potřeba žádný 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"

Stav k 2026-07-28.

Vyzkoušejte Thunderbit pro extrakci webových dat

Rozhodnutí a upozornění

V testované matici běžný Google Chrome 150 odmítl --disable-extensions-except spolu s --load-extension, zatímco Chrome for Testing 149 a 151 rozšíření načetly. Chrome odmítnutí zapsal na úrovni WARNING: "--load-extension is not allowed in Google Chrome, ignoring." Formulace podporuje interpretaci s brandovaným buildem a verze mezi dvěma fungujícími body vylučují jednoduché lineární odstranění funkce, ale build i verze zůstávají provázané, pokud nemáte větev se stejnou verzí na jiném buildu nebo důkaz ze zdrojáku/konfigurace.

Pro připnutý harness rozšíření používejte explicitně verzované executable prohlížeče a ověřujte service worker i marker content scriptu. V tomhle nastavení s Playwrightem 1.56.0 vyžadoval export rozšíření zachycení přes CDP do adresáře a dorazil pod jiným názvem souboru. Stub načtený z příkazové řádky se navíc na testovaném fixture file:// normálně injektoval; jiné instalační cesty se netestovaly.

Vyzkoušejte Thunderbit pro extrakci webových dat Get Started Free

Časté dotazy

Byl --load-extension z Chrome úplně odstraněn? Ne. Chrome for Testing 149.0.7827.55 i 151.0.7922.10 z tohoto přepínače načetly unpacked MV3 stub a prošly všech šest bodovaných kontrol. Běžný Google Chrome 150.0.7871.187 to odmítl a zaznamenal "--load-extension is not allowed in Google Chrome, ignoring". To podporuje, ale nedokazuje, gate vázaný na brandované sestavení: chování vylučuje jednoduché monotónní odstranění, ale pořád je kompatibilní se scénářem, že šlo o regresi v Chrome 150, která byla v 151 opravena.

Proč nevidím žádnou chybu a jak poznám „nikdy se nenačetlo“ od „načetlo se to, ale potichu selhalo“? Varování se v defaultní verbositě nevypisuje. Spusť Chrome s --enable-logging=stderr a objeví se hned; bez toho Chrome normálně nastartuje, ale jeho služba rozšíření přepínače ignoruje a první symptom v harnessu je timeout selektoru. Pro rozlišení „nikdy se nenačetlo“ od chyby při injektování použij dva nezávislé signály: MV3 background service worker a marker content scriptu v DOM cílové stránky. V testované větvi stock Chrome se neobjevil ani jeden; v obou větvích Chrome for Testing se objevily oba.

Co tedy mám použít pro automatizaci rozšíření místo toho? Úspěšné větve používaly připnuté Chrome for Testing executable přes executablePath. Chromium spravované Playwrightem je další možná automatizační binárka, ale v tomhle testu nešlo o samostatnou větev a nemělo by se bez ověření identifikovaného executable popisovat jako stejná distribuce.

Proč se waitForEvent('download') nikdy nevrátí, když rozšíření exportuje soubor? V tomhle nastavení MV3/Playwright 1.56.0 se event nevrátil a nebyl nabídnut žádný suggested filename. Harness otevřel CDP session, zavolal Browser.setDownloadBehavior s explicitním adresářem a pak soubor načetl z disku. V testovaných bězích přežily bytes CSV, ale probe-export.csv dorazil jako download.csv; širší kombinace rozšíření a prohlížečů se netestovaly.

Co to naopak neříká — o URL file:// a o běžném Chromu obecně? Dvě hranice, opačným směrem. Content scripts na file:// URL fungují pro rozšíření načtená z příkazové řádky — testováno na obou Chrome for Testing buildích, kde se script normálně injektoval a ID rozšíření bylo správné, takže časté tvrzení, že nefungují kvůli chybějícímu file accessu, je pro tuhle instalační cestu špatně. Fixture přes HTTP je pořád lepší praxe, protože to víc připomíná reálný cíl, ne protože by file:// blokovalo injektování. A na druhou stranu: nic z toho netvrdí, že běžný Chrome neumí spouštět rozšíření. Měřila se jen příkazová řádka s --load-extension. Instalace balíčku .crx, režim developer mode ani enterprise allowlist policy se netestovaly a žádné tvrzení o nich nepadá. Rozsah je ta jedna dvojice přepínačů, kterou vám automation návody říkají používat.