Chrome berättar varför `--load-extension` slutade fungera. Du ser bara inte meddelandet.

Två flaggor dyker ofta upp i exempel för tilläggsautomatisering:

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

Äldre guider pekar Puppeteer eller Playwright mot en installerad Chrome och skickar båda flaggorna.

I den vanliga Google Chrome 150-byggnad som testades här startade webbläsaren utan kommandoradsfel, men tilläggstjänsten ignorerade båda flaggorna. Automatiseringen kopplade upp sig som vanligt och tillägget saknades; det fördröjda symptomet var en timeout på en selektor i det här testupplägget.

Chrome loggade avslaget på en rad, men först efter att stderr-loggning hade aktiverats.

Den viktigaste slutsatsen handlar om jämförelsen mellan olika webbläsarbyggen. Två senare avsnitt är uttryckligen anteckningar om testmiljön: ett om nedladdningar som utlöses av tillägg och ett om denna kommandoradsinstallation på file://-fixtures. Thunderbit är själv ett Chrome-tillägg, så vi har ett direkt intresse i just det här problemet; Thunderbit var dock inte testmålet.

Raden

Lägg till --enable-logging=stderr och starta den vanliga Chrome med de flaggorna:

Officiell referens: Chromium extension service source.

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

Skicka bara --load-extension och du får en egen varning, från en annan rad i samma fil:

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

Chrome for Testing, med identiska flaggor, skriver inte ut någon av dem.

"Inte tillåtet i Google Chrome." Varningen pekar tydligt mot en regel som gäller de varumärkta byggena och är den mest rimliga tolkningen av det observerade avslaget. Den bevisar att den här vanliga Google Chrome 150-byggnaden ignorerade flaggan och visar var i koden beslutet kommer från. Den bevisar däremot inte på egen hand att versionen saknar betydelse, och den avslöjar inte heller vilken implementation som skiljer ut beteendet.

Allt nedan handlar om bekräftelse och följder.

Bekräftat genom beteendet

Ett minimalt MV3-tillägg, byggt för det här testet och inte nedladdat, använder ett content script, popup, ett meddelandesvar fram och tillbaka, DOM-utläsning och export via chrome.downloads mot ett lokalt fixture med tre produkter. Testmiljön registrerar sex numrerade kontroller: service worker registrerad; tilläggsmarkör med ID; content-script-markör matchar; popup-knappen synlig; popupen returnerar tre rader; fångad CSV innehåller den förväntade raden. En separat överensstämmelsekontroll jämför de oberoende signalerna från service worker och sidmarkör.

Tre byggen kördes med samma explicita tilläggsflaggor, samma tilläggskatalog, samma HTTP-fixture, headed persistent-context-läge och en ny profil per gren. Stock-grenen gick via channel: 'chrome'; de två fungerande grenarna använde explicita sökvägar till exekverbara filer. Versionssträngarna lästes tillbaka via CDP.

Råa sammanfattningar: Chrome for Testing 149, vanlig Chrome 150, Chrome for Testing 151 och stderr-varningar.

Chrome for Testing 149 är med medvetet: den är äldre än den vanliga byggnaden den jämförs med. Om möjligheten hade tagits bort vid ett versionsskifte borde en äldre byggnad ligga på den fungerande sidan av gränsen och den misslyckade vara den nyaste. I stället ligger den misslyckade byggnaden mellan två fungerande, vilket utesluter en enkel versionstrend.

Den tabellen bevisar inte i sig att spärren är byggbaserad, och det är viktigt att vara exakt med varför. Den enda misslyckade rutan är samtidigt den enda vanliga Chrome-rutan och den enda 150-rutan — byggnad och version är alltså fortfarande perfekt sammanblandade i den här designen. Tre grenar utesluter monoton borttagning; de kan inte utesluta att funktionen ”föll bort i 150 och kom tillbaka i 151”. För att få fram det enbart via beteendet skulle man behöva en ruta som den här maskinen inte kan producera: Chrome for Testing 150, eller en varumärkt byggnad i någon annan version.

Varningen stärker tolkningen att det är just de varumärkta byggena som spärras, eftersom den uttryckligen nämner Google Chrome, medan de tre beteendegrenarna bara utesluter en enkel monoton försvinnande funktion. För att bevisa en mekanism som är oberoende av version skulle man fortfarande behöva en jämförelse mellan olika byggen i samma version eller en källa-/konfigurationshänvisning.

De länkade artefakterna per bygge visar den sammanfattade körningen för varje gren; den här artikeln publicerar inte en rad-för-rad-matris för det extra antalet starter, så det antalet används inte som oberoende bevis.

En signal räcker inte för att säga "den laddades inte"

Den första versionen av detta test avgjorde om tillägget hade laddats genom att leta efter en markör som content scriptet skriver in i sidan — och det var också så man avgjorde om content scriptet hade körts. En och samma observation, använd som två mätningar. Om markören saknas kan du inte skilja mellan "tillägget laddades aldrig" och "det laddades men content scriptet injicerades inte", och de har helt olika åtgärder.

MV3-tillägg kör en bakgrundsbaserad service worker, och Playwright exponerar service workers direkt. Det är en oberoende signal: den rör aldrig sidan och kan därför inte blandas ihop med injicering. Det nuvarande testet läser båda och kontrollerar att de stämmer överens.

I alla tre körningar gjorde de det. I vanlig Chrome registrerades ingen service worker över huvud taget — den starka formen av påståendet. I båda Chrome for Testing-byggen dök worker upp på chrome-extension://<id>/background.js innan sidan ens öppnades.

Använd Chrome for Testing, som du kanske redan har

De två fungerande grenarna använde explicita Chrome for Testing-exekverbara filer som rapporterade versionerna 149.0.7827.55 och 151.0.7922.10. Peka Playwrights executablePath mot den låsta exekverbara filen i stället för att låta den hitta vanlig Chrome via channel: 'chrome'. npx playwright install chromium installerar ett Chromium-bygge som Playwright själv hanterar; det kan också fungera bra för automatisering, men det är inte samma distributionslabel som de två Chrome for Testing-grenarna och var inte en fjärde gren i den här jämförelsen.

Officiell referens: Chrome for Testing announcement.

Relaterad genomgång: Chrome extension permissions audit.

Det finns också en praktisk fördel som lever längre än just den här kraschen. Vanlig Chrome uppdateras automatiskt i bakgrunden, så ett test som passerar idag kan falla på tisdag av skäl som ingen commit förklarar. Chrome for Testing är låst till en version. För allt som ska fortsätta ha mening om tre månader väger det tyngre än bekvämlighet.

Anteckning från testmiljön: fånga exporten från tillägget

För ett scraping-tillägg är exporten själva poängen — det är där fält tappas bort, teckenkodningar blir fel och nästlade data plattas ut på fel sätt. Två saker om detta är dåligt dokumenterade, och båda ställer till det.

I denna MV3-/Playwright 1.56.0-miljö utlöstes inte Playwrights download-event av chrome.downloads. När tillägget exporterade en CSV via API:t gav waitForEvent('download') inget resultat. Testet fångade filen genom att öppna en CDP-session, sätta nedladdningsbeteendet uttryckligen och läsa utmappningen:

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

I samma miljö behöll inte CDP-fångsten det filnamn som begärdes. Rubriken och alla tre raderna fanns kvar intakta, men probe-export.csv hamnade som download.csv. Detta är observerat beteende för de testade webbläsarbyggena och konfigurationen, inte en dokumenterad invariant för alla tilläggsnedladdningar. Kontrollera innehåll separat från filnamn.

Anteckning från testmiljön: file://-beteendet för denna installationsväg

När detta verifierades visade sig ett mycket återupprepat påstående vara fel, och det hade till och med smugit sig in i ett tidigare utkast av just den här artikeln: att content scripts inte körs på file://-sidor eftersom tillägg saknar filåtkomst som standard.

Mätt i båda Chrome for Testing-byggena, när tillägget laddades från kommandoraden och man gick direkt till file:///…/fixture/index.html: content scriptet injiceras som vanligt. Markör finns, tilläggs-ID stämmer, i båda byggen. Kommandoradsladdade uppackade tillägg får filåtkomst; den där "ge filåtkomst"-knappen som många minns gäller en annan installationsväg.

Att servera fixtures via HTTP är fortfarande bättre som standard, eftersom en file://-sida inte liknar ett riktigt mål. Men det är ett argument om realism, inte ett tekniskt krav, och den ofta angivna förklaringen är fel.

Vad detta inte fastställer

• Spärrens implementation är bara så djup som varningstexten. Chrome säger att flaggorna inte är tillåtna i den här byggnaden och anger källfilen. Om det beror på buildkonfiguration, policykoppling eller något annat lästes inte ut ur koden.
• Detta är bara en maskin. macOS på arm64, en vanlig patchversion, två Chrome for Testing-byggen. Chrome rör sig snabbt nog för att detta måste verifieras om, inte bara citeras.
• Detta gäller bara --load-extension-vägen. Packade .crx-installationer, utvecklarlägesladdning och företagslistor testades inte. Ingenting här stödjer påståendet att "vanlig Chrome inte kan köra tillägg".
• Tillägget är en specialbyggd stub. Det övar de mekanismer som varje scraper-tillägg använder, men ett riktigt tillägg är större och kan misslyckas på sätt som en stub inte kan.

Vad jag hade fel om på vägen hit

Det är värt att säga det rakt ut, eftersom båda misstagen är sådana som kan överleva granskning när resultatet ser rätt ut.

Den första versionen av den här texten sa att felet var tyst, att ingen loggrad fanns, och att mekanismen var omöjlig att veta — att den som påstod sig veta bara gissade. Mekanismen låg dock ett flaggbyte bort, och Chrome hade skrivit ut den på WARNING-nivå hela tiden. "Jag hittade det inte" hade formulerats som "det går inte att hitta."

Det andra var file://-påståendet ovan: det kom från anteckningar och skrevs med en säker förklaring innan det hade testats. En körning falsifierade det.

Mönstret är detsamma i båda fallen. Ett rimligt påstående som ingen ifrågasätter, som förs vidare eftersom det känns onödigt att kontrollera. Lösningen är inte mer försiktighet i språket, utan en regel för vad som får sägas: ett påstående som inte kan spåras till en körning publiceras inte.

Kommandon som användes i den lokala testmiljön

Den versionsstyrda proben, tilläggsstubben, fixturet och de råa sammanfattningarna är länkade här, men detta är ännu inte ett fristående publikt reproduktionspaket. Exakta nedladdningskällor och checksummor för Chrome for Testing 149 och 151 är inte dokumenterade i artikeln, och sökvägarna till exekverbara filer nedan var lokala indata. Publicera dessa webbläsarkällor plus en stabil repository-commit innan hela jämförelsen presenteras som oberoende reproducerbar.

Relaterad genomgång: Playwright review.

cd harness
npm install playwright@1.56.0
npx playwright install chromium      # Playwrights Chromium; inte de två CfT-grenarna nedan
(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

Samma script och samma explicita tilläggsargument användes för alla tre grenar, men hur exekverbara filer hittades skiljde sig åt: CHANNEL=chrome för vanlig Chrome och EXE för de två Chrome for Testing-binärerna. Versionen i varje utdatafil läses från webbläsaren, inte från etiketten.

För varningsraden behövs ingen testmiljö:

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

Prova Thunderbit för webbdatastrahering

Slutsats och förbehåll

I den testade matrisen vägrade vanlig Google Chrome 150 --disable-extensions-except tillsammans med --load-extension, medan Chrome for Testing 149 och 151 laddade tillägget. Chrome loggade avslaget på WARNING-nivå: "--load-extension is not allowed in Google Chrome, ignoring." Formuleringen talar för en varumärkesbunden byggregel, och versionssandwichen utesluter enkel monoton borttagning, men byggnad och version är fortfarande sammanblandade utan en jämförelse mellan olika byggen i samma version eller stöd från källa/konfiguration.

För ett låst testupplägg för tillägg, använd en webbläsarexekverbar fil med tydlig versionslåsning och verifiera både service worker och content-script-markör. I den här Playwright 1.56.0-konfigurationen krävde exporten från tillägget CDP-baserad fångst till katalog och hamnade under ett annat filnamn. Den kommandoradsladdade stubben injicerades också på det testade file://-fixturet; andra installationsvägar testades inte.

Prova Thunderbit för webbdatastrahering Get Started Free

Vanliga frågor

Är --load-extension borttaget helt från Chrome? Nej. Chrome for Testing 149.0.7827.55 och 151.0.7922.10 laddade båda den uppackade MV3-stubben via den flaggan och klarade alla sex kontroller. Vanlig Google Chrome 150.0.7871.187 vägrade och loggade "--load-extension is not allowed in Google Chrome, ignoring". Det stöder, men bevisar inte, en spärr kopplad till de varumärkta byggena: beteendet utesluter enkel monoton borttagning, medan en Chrome-150-specifik regression som återställdes i 151 fortfarande passar den tregrenade designen.

Varför ser jag inget fel, och hur skiljer jag "aldrig laddad" från "laddad men misslyckades tyst"? Varningen skrivs inte ut på standardnivån. Starta med --enable-logging=stderr så syns den direkt; utan det startar Chrome normalt men dess tilläggstjänst ignorerar flaggorna, och det första symptomet i testet är en timeout på en selektor. För att skilja “aldrig laddad” från injiceringsfel, använd två oberoende signaler: MV3-bakgrundens service worker och en content-script-markör i mål-DOM:en. I den testade vanliga Chrome-grenen dök ingen av dem upp; i båda Chrome for Testing-grenarna gjorde de det.

Vad ska jag använda i stället för att automatisera tillägg? De fungerande grenarna använde låsta Chrome for Testing-exekverbara filer via executablePath. Playwright-hanterad Chromium är en annan möjlig automationsbinär, men den var inte en gren i testet och ska inte beskrivas som samma distribution utan att kontrollera den upplösta exekverbara filen.

Varför löser sig aldrig waitForEvent('download') när tillägget exporterar en fil? I denna MV3-/Playwright 1.56.0-konfiguration löstes eventet inte, och inget föreslaget filnamn erbjöds. Testet öppnade en CDP-session, anropade Browser.setDownloadBehavior med en explicit katalog och läste sedan filen från disk. I de testade körningarna överlevde CSV-bitarna, men probe-export.csv landade som download.csv; andra kombinationer av tillägg och webbläsare testades inte.

Vad säger detta inte — om file://-URL:er och om vanlig Chrome i allmänhet? Två gränser, i motsatt riktning. Content scripts fungerar på file://-URL:er för tillägg som laddas från kommandoraden — testat i båda Chrome for Testing-byggena, där scriptet injicerades normalt och tilläggs-ID:t rapporterades korrekt, så det vanliga påståendet att de inte gör det (med hänvisning till att tillägg saknar filåtkomst som standard) är fel för just denna installationsväg. Att servera fixtures över HTTP är fortfarande bästa praxis eftersom det liknar ett verkligt mål, inte för att file:// blockerar injicering. I andra riktningen: inget här säger att vanlig Chrome inte kan köra tillägg. Bara --load-extension-vägen på kommandoraden mättes. Packade .crx-installationer, utvecklarlägesladdning och företagslistor testades inte, och inget påstående görs om dem. Omfattningen är just det flaggpar som automatiseringsguider brukar säga att du ska använda.