Chrome mówi Ci, dlaczego `--load-extension` przestał działać. Po prostu tego nie widzisz.

Dwa przełączniki bardzo często pojawiają się w przykładach automatyzacji rozszerzeń:

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

Starsze poradniki każą Puppeteerowi albo Playwrightowi wskazać zainstalowanego Chrome i przekazać oba flagi.

W testowanej tutaj standardowej wersji Google Chrome 150 przeglądarka wystartowała bez błędu w wierszu poleceń, ale usługa rozszerzeń zignorowała oba przełączniki. Automatyzacja połączyła się normalnie, rozszerzenia nie było, a później objawiło się to timeoutem selektora w tym harnessie.

Chrome zapisał odmowę w jednej linijce, ale dopiero po włączeniu logowania stderr.

Najważniejszy wniosek wynika z porównania różnych buildów przeglądarki. Dwie późniejsze sekcje to wyraźnie notatki z harnessu: jedna dotyczy pobierania uruchamianego przez rozszerzenie, a druga tego sposobu instalacji z linii poleceń na fixture file://. Thunderbit sam jest rozszerzeniem Chrome, więc mamy bezpośredni interes w tym problemie; Thunderbit nie był jednak obiektem testu.

Ta linia

Dodaj --enable-logging=stderr i uruchom standardowego Chrome z tymi flagami:

Oficjalne odniesienie: źródło usługi rozszerzeń Chromium.

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

Jeśli podasz samo --load-extension, dostaniesz osobne ostrzeżenie z innej linii tego samego pliku:

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

Chrome for Testing, uruchomiony z identycznymi flagami, nie wypisuje żadnego z tych komunikatów.

„Nie jest dozwolone w Google Chrome.” To ostrzeżenie wskazuje na regułę związaną z markowanym buildem jako najbardziej prawdopodobne wyjaśnienie odmowy, którą zaobserwowano. Pokazuje, że ten standardowy build Google Chrome 150 zignorował flagę i wskazuje miejsce w źródle. Nie dowodzi jednak samodzielnie, że wersja nie ma znaczenia, ani nie ujawnia mechanizmu rozróżniającego implementację.

Wszystko poniżej to potwierdzenie i konsekwencje.

Potwierdzenie behawioralne

Minimalne rozszerzenie MV3, zbudowane specjalnie na potrzeby tego testu, a nie pobrane z zewnątrz, używa skryptu treści, popupu, round-trip wiadomości, ekstrakcji DOM i eksportu chrome.downloads względem lokalnego fixture z trzema produktami. Harness zapisuje sześć numerowanych sprawdzeń: zarejestrowano service worker; znacznik rozszerzenia ma ID; znacznik skryptu treści się zgadza; przycisk popupu jest widoczny; popup zwraca trzy wiersze; przechwycony CSV zawiera oczekiwany wiersz. Osobna asercja zgodności porównuje niezależne sygnały z service workera i znacznika na stronie.

Trzy buildy używały tych samych jawnych flag rozszerzenia, tego samego katalogu rozszerzenia, fixture HTTP, trybu headed persistent-context i świeżego profilu dla każdej gałęzi. Gałąź stock była uruchamiana przez channel: 'chrome'; dwa przechodzące warianty używały jawnych ścieżek do pliku wykonywalnego. Wersje odczytano z browsera przez CDP.

Surowe podsumowania: Chrome for Testing 149, standardowy Chrome 150, Chrome for Testing 151 oraz ostrzeżenia stderr.

Chrome for Testing 149 został dodany celowo: jest starszy niż porównywany build stock. Gdyby funkcjonalność usunięto wraz z podbiciem wersji, starszy build powinien znajdować się po stronie działającej, a nieudany build powinien być najnowszy. Tymczasem wadliwy build leży pomiędzy dwoma działającymi, co wyklucza prostą progresję wersji.

Sama ta tabela nie dowodzi jednak, że blokada zależy od builda, i warto precyzyjnie wyjaśnić dlaczego. Jedyna nieudana komórka jest zarazem jedyną komórką stock i jedyną komórką 150 — build i wersja są tu nadal idealnie splecione. Trzy warianty wykluczają monotoniczne usunięcie; nie wykluczają scenariusza „regresja w 150, naprawa w 151”. Aby wywnioskować to wyłącznie z zachowania, potrzebna byłaby komórka, której ta maszyna nie potrafi wygenerować: Chrome for Testing 150 albo build markowany z inną wersją.

Ostrzeżenie wzmacnia interpretację związaną z markowanym buildem, ponieważ wprost wymienia Google Chrome, natomiast behawior trzech wariantów wyklucza tylko proste monotoniczne usunięcie. Do udowodnienia mechanizmu niezależnego od wersji nadal potrzebne byłoby porównanie między buildami tej samej wersji albo cytat ze źródła / konfiguracji.

Powiązane artefakty dla poszczególnych buildów pokazują skrócony przebieg testu dla każdej gałęzi; ten artykuł nie publikuje pełnej matrycy krok po kroku dla dodatkowej liczby uruchomień, więc nie wykorzystuje tej liczby jako niezależnego dowodu.

Jeden sygnał to za mało, by powiedzieć „nie załadowało się”

Pierwsza wersja tego testu sprawdzała, czy rozszerzenie się załadowało, patrząc na znacznik, który skrypt treści zapisuje w stronie — i tak samo ustalała, czy skrypt treści w ogóle się uruchomił. Jeden odczyt użyty jako dwa pomiary. Jeśli znacznika brakuje, nie wiadomo, czy „rozszerzenie nigdy się nie załadowało”, czy „załadowało się, ale skrypt treści się nie wstrzyknął”, a to są zupełnie różne problemy i naprawy.

Rozszerzenia MV3 uruchamiają background service worker, a Playwright udostępnia service workery bezpośrednio. To niezależny sygnał: nie dotyka strony, więc nie da się go pomylić z wstrzyknięciem. Obecny test odczytuje oba sygnały i sprawdza, czy są zgodne.

We wszystkich trzech uruchomieniach są zgodne. W standardowym Chrome nigdy nie zarejestrowano service workera — to mocniejsza wersja tej tezy. W obu buildach Chrome for Testing worker pojawiał się pod chrome-extension://<id>/background.js, zanim jeszcze otwarto stronę.

Użyj Chrome for Testing, który być może już masz

Dwa działające warianty używały jawnych plików wykonywalnych Chrome for Testing, raportujących wersje 149.0.7827.55 i 151.0.7922.10. Wskaż w Playwright executablePath na przypięty binarny plik wykonywalny zamiast rozwiązywać standardowego Chrome przez channel: 'chrome'. npx playwright install chromium instaluje Chromium zarządzane przez Playwright; też może się przydać do automatyzacji, ale nie jest tym samym oznaczeniem dystrybucji co dwa warianty Chrome for Testing i nie był czwartą gałęzią w tym porównaniu.

Oficjalne odniesienie: ogłoszenie Chrome for Testing.

Powiązany przegląd: audyt uprawnień rozszerzenia Chrome.

Jest też jedna korzyść, która zostaje na dłużej niż ten konkretny problem. Standardowy Chrome aktualizuje się automatycznie w tle, więc suite, który dziś przechodzi, we wtorek może już failować z powodów, których żaden commit nie wyjaśnia. Chrome for Testing jest przypięty. Dla wszystkiego, czego wynik ma nadal coś znaczyć za trzy miesiące, to ważniejsze niż wygoda.

Notatka z harnessu: przechwytywanie eksportu rozszerzenia

Dla rozszerzenia do scrapingu eksport jest sednem sprawy — to tam gubią się pola, psują kodowania i źle spłaszczają dane zagnieżdżone. Dwie rzeczy związane z tym procesem nie są udokumentowane i obie potrafią ugryźć.

W tym harnessie MV3 / Playwright 1.56.0 chrome.downloads nie wywołał zdarzenia pobierania Playwrighta. Gdy rozszerzenie eksportowało CSV przez API, waitForEvent('download') nie kończyło się sukcesem. Harness przechwycił plik, otwierając sesję CDP, ustawiając jawnie politykę pobierania i czytając katalog wyjściowy:

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

W tym samym harnessie ścieżka przechwytywania przez CDP nie zachowała żądanej nazwy pliku. Nagłówek i wszystkie trzy wiersze przetrwały bez zmian, ale probe-export.csv zapisał się jako download.csv. To zaobserwowane zachowanie dla testowanych buildów przeglądarki i konfiguracji, a nie udokumentowany invariant dla każdego pobierania z rozszerzenia. Sprawdzaj osobno zawartość i nazwę pliku.

Notatka z harnessu: zachowanie file:// dla tej ścieżki instalacji

Podczas weryfikacji tego fragmentu okazało się, że jedna szeroko powtarzana teza jest fałszywa, i trafiła nawet do wcześniejszego szkicu tego artykułu: że skrypty treści nie działają na stronach file://, bo rozszerzenia nie mają domyślnie dostępu do plików.

Zmierzono to na obu buildach Chrome for Testing, ładując rozszerzenie z linii poleceń i przechodząc bezpośrednio do file:///…/fixture/index.html: skrypt treści wstrzykuje się normalnie. Znacznik jest obecny, ID rozszerzenia się zgadza, oba buildy. Rozszerzenia unpacked uruchamiane z linii poleceń mają dostęp do plików; przełącznik „zezwól na dostęp do plików”, który ludzie pamiętają, dotyczy innej ścieżki instalacji.

Serwowanie fixture przez HTTP nadal jest lepszym domyślnym wyborem, bo strona file:// w niczym nie przypomina realnego celu. To jednak argument za realizmem, a nie wymóg techniczny — i zwykle podawany mechanizm jest po prostu błędny.

Czego to nie dowodzi

• Implementacja blokady jest widoczna tylko tak głęboko, jak sam komunikat ostrzegawczy. Chrome mówi, że te flagi nie są dozwolone w tym buildzie i wskazuje plik źródłowy. Nie odczytano jednak ze źródła, czy wynika to z konfiguracji builda, polityki, czy czegoś innego.
• To jedna maszyna. macOS na arm64, jedna wersja patch standardowego Chrome, dwa buildy Chrome for Testing. Chrome zmienia się wystarczająco szybko, że to wymaga ponownej weryfikacji, a nie samego cytowania.
• To tylko ścieżka --load-extension. Instalacje spakowanych .crx, ładowanie w trybie deweloperskim i enterprise allowlist policies nie były testowane. Nic tutaj nie wspiera tezy „standardowy Chrome nie uruchamia rozszerzeń”.
• Rozszerzenie jest specjalnie przygotowanym stubem. Testuje mechanikę, której używa każde rozszerzenie do scrapingu, ale prawdziwe rozszerzenie jest większe i może psuć się w sposób, którego stub nie ujawni.

Co po drodze opisałem błędnie

Warto powiedzieć to wprost, bo oba błędy należą do tych, które przechodzą przez recenzję, gdy wynik wygląda poprawnie.

Pierwsza wersja tego tekstu mówiła, że awaria była cicha, że nie było żadnej linii w logu i że mechanizmu nie da się poznać — że każdy, kto twierdzi inaczej, zgaduje. Mechanizm był o jedną flagę dalej, a Chrome cały czas wypisywał go z poziomem WARNING. „Nie umiałem tego znaleźć” zapisano jako „tego nie da się znaleźć”.

Drugi błąd dotyczył powyższego twierdzenia o file://: zostało przeniesione z notatek i opatrzone pewnym siebie mechanizmem zanim zostało przetestowane. Jeden przebieg je obalił.

W obu przypadkach wzorzec jest ten sam. Brzmiące sensownie stwierdzenie, którego nikt nie podważy, przenoszone dalej, bo sprawdzenie wydaje się zbędne. Naprawa nie polega na większej ostrożności w stylu, tylko na zasadzie dotyczącej tego, co wolno stwierdzić: twierdzenie, którego nie da się przypisać do konkretnego uruchomienia, nie trafia do publikacji.

Komendy użyte w lokalnym harnessie

Wersjonowane probe, stub rozszerzenia, fixture i surowe podsumowania są tu podlinkowane, ale nie jest to jeszcze samodzielny publiczny pakiet do reprodukcji. Dokładne źródła pobrania Chrome for Testing 149 i 151 oraz ich checksumy nie są zapisane w artykule, a poniższe ścieżki do plików wykonywalnych były lokalnymi danymi wejściowymi. Opublikuj te źródła przeglądarek wraz ze stabilnym commitem repozytorium, zanim przedstawisz pełne porównanie jako niezależnie odtwarzalne.

Powiązany przegląd: przegląd Playwright.

cd harness
npm install playwright@1.56.0
npx playwright install chromium      # Chromium zarządzane przez Playwright; nie dwa warianty CfT poniżej
(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

Ten sam skrypt i te same jawne argumenty rozszerzenia zostały użyte dla wszystkich trzech wariantów, ale rozwiązywanie pliku wykonywalnego różniło się: CHANNEL=chrome dla standardowego Chrome i EXE dla dwóch binarek Chrome for Testing. Wersja w każdym pliku wynikowym jest odczytywana z przeglądarki, a nie ufana na podstawie etykiety.

Dla linii ostrzeżenia harness nie jest potrzebny:

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

Stan na 2026-07-28.

Wypróbuj Thunderbit do ekstrakcji danych z sieci

Decyzja i zastrzeżenia

W testowanej macierzy standardowy Google Chrome 150 odrzucał --disable-extensions-except wraz z --load-extension, podczas gdy Chrome for Testing 149 i 151 ładowały rozszerzenie. Chrome zapisał odmowę z poziomem WARNING: "--load-extension is not allowed in Google Chrome, ignoring." Sformułowanie wspiera interpretację związaną z markowanym buildem, a wersyjny „sandwich” wyklucza proste monotoniczne usunięcie, ale build i wersja nadal są splecione bez wariantu cross-build dla tej samej wersji albo dowodów ze źródła / konfiguracji.

Do przypiętego harnessu rozszerzenia użyj jawnie wersjonowanego pliku wykonywalnego przeglądarki i sprawdzaj service worker oraz znacznik skryptu treści. W tym setupie Playwright 1.56.0 eksport rozszerzenia wymagał przechwycenia katalogu przez CDP i trafiał pod inną nazwą pliku. Stub uruchamiany z linii poleceń wstrzykiwał się też do testowanego fixture file://; innych ścieżek instalacji nie sprawdzono.

Wypróbuj Thunderbit do ekstrakcji danych z sieci Get Started Free

FAQ

Czy --load-extension został całkiem usunięty z Chrome? Nie. Chrome for Testing 149.0.7827.55 i 151.0.7922.10 oba ładowały rozpakowany stub MV3 z tej flagi i przechodziły wszystkie sześć punktowanych testów. Standardowy Google Chrome 150.0.7871.187 odrzucił tę flagę i zapisał "--load-extension is not allowed in Google Chrome, ignoring". To wspiera, ale nie dowodzi, blokadę związaną z markowanym buildem: zachowanie wyklucza proste monotoniczne usunięcie, ale nadal zgodne jest z regresem specyficznym dla Chrome 150, naprawionym w 151.

Dlaczego nie widzę żadnego błędu i jak odróżnić „nigdy się nie załadowało” od „załadowało się i cicho padło”? Ostrzeżenie nie pojawia się przy domyślnej szczegółowości logowania. Uruchom z --enable-logging=stderr, a pojawi się od razu; bez tego Chrome startuje normalnie, ale jego usługa rozszerzeń ignoruje flagi, a pierwszym objawem w harnessie jest timeout selektora. Aby rozdzielić „nigdy się nie załadowało” od błędu wstrzyknięcia, użyj dwóch niezależnych sygnałów: background service workera MV3 i znacznika skryptu treści w docelowym DOM. W testowanej gałęzi standardowego Chrome żaden z nich się nie pojawił; w obu gałęziach Chrome for Testing pojawiły się oba.

Czego użyć zamiast tego do automatyzacji rozszerzeń? Działające warianty używały przypiętych plików wykonywalnych Chrome for Testing przez executablePath. Chromium zarządzane przez Playwright to inna możliwa binarka do automatyzacji, ale nie było wariantem w tym teście i nie powinno być opisywane jako ta sama dystrybucja bez sprawdzenia rzeczywistego pliku wykonywalnego.

Dlaczego waitForEvent('download') nigdy się nie kończy, gdy rozszerzenie eksportuje plik? W tym setupie MV3 / Playwright 1.56.0 zdarzenie nie kończyło się sukcesem i nie było podanej sugerowanej nazwy pliku. Harness otwierał sesję CDP, wywoływał Browser.setDownloadBehavior z jawnym katalogiem, a potem odczytywał plik z dysku. W testowanych uruchomieniach bajty CSV przetrwały, ale probe-export.csv pojawiał się jako download.csv; szerszych kombinacji rozszerzeń i przeglądarek nie testowano.

Czego to nie mówi — o URL-ach file:// i o standardowym Chrome ogólnie? Dwie granice, w przeciwnych kierunkach. Skrypty treści działają na URL-ach file:// dla rozszerzeń ładowanych z linii poleceń — testowane na obu buildach Chrome for Testing, z normalnym wstrzyknięciem skryptu i poprawnym ID rozszerzenia, więc popularne twierdzenie, że nie działają (bo rozszerzenia nie mają domyślnie dostępu do plików), jest błędne dla tej ścieżki instalacji. Serwowanie fixture przez HTTP nadal jest lepszą praktyką, bo przypomina realny cel, a nie dlatego, że file:// blokuje wstrzyknięcie. W drugą stronę: nic z tego nie mówi, że standardowy Chrome nie uruchamia rozszerzeń. Zmierzono tylko ścieżkę wiersza poleceń --load-extension. Instalacji spakowanego .crx, ładowania w trybie deweloperskim ani enterprise allowlist policies nie testowano i nie formułuje się tu żadnych twierdzeń o nich. Zakres dotyczy jednej pary flag, którą instrukcje automatyzacji każą zwykle stosować.