Znane problemy z migracją do platformy Manifest V3

Na tej stronie znajdziesz informacje o lukach w platformie, które zostały usunięte podczas przejścia na Manifest V3, oraz odpowiedzi na najczęstsze pytania dotyczące migracji.

Wyeliminowane braki na platformie

Aby rozwiązać typowe problemy blokujące migrację, dodaliśmy te funkcje:

  1. Obsługa obsługi plików w ChromeOS jako zamiennika chrome.fileBrowserHandler (Chrome 120).
  2. Obsługa skryptów użytkownika: umożliwia rejestrowanie skryptów treści z dowolnym kodem za pomocą nowego interfejsu userScripts API (Chrome 120).
  3. Dodatkowe silne sygnały podtrzymujące działanie komponentu service worker w przypadku niektórych operacji trwających dłużej niż 5 minut.
    • Dodano w Chrome 116 na urządzenia permissions.request(), desktopCapture.chooseDesktopMedia(), identity.launchWebAuthFlow() i management.uninstall().
    • Dodano w Chrome 118 na chrome.debugger.
  4. Zwiększ liczbę statycznych i włączonych zestawów reguł w przypadku deklaratywnego żądania sieciowego (DNR). Liczba włączonych statycznych zestawów reguł wzrosła z 10 do 50, a łączna liczba statycznych zestawów reguł z 50 do 100 (Chrome 120).
  5. Rozszerzenie funkcji dokumentu poza ekranem, aby obsługiwać więcej powodów używania dokumentu poza ekranem. Dodano GEOLOCATION w Chrome 116.
  6. Ulepszenie obsługi interfejsu chrome.tabCapture API (Chrome 116):
    • Obsługa wywoływania getMediaStreamId() ze skryptu service worker.
    • Obsługa uzyskiwania MediaStream z identyfikatora strumienia w dokumencie poza ekranem.
  7. Wydłużanie czasu życia skryptów service worker, gdy istnieją aktywne WebSocket połączenia (Chrome 116).

Najczęstsze pytania dotyczące platformy Manifest V3

P: Czy planujemy obsługę trwałych Service Workerów?
O: Jednym z głównych powodów przejścia ze skryptów działających w tle na skrypty service worker jest bardziej wydajny pod względem pamięci model programowania oparty na zdarzeniach, który wynika z krótkotrwałego charakteru skryptów service worker. W związku z tym nie planujemy obsługi trwałych service workerów. Aby jednak sprostać konkretnym potrzebom deweloperów rozszerzeń, nadal wprowadzamy wiele ulepszeń w zakresie procesów w tle. W szczególności:

  • Wszystkie zdarzenia rozszerzenia i wywołania interfejsu API wydłużą czas działania skryptu service worker.
  • W przypadku wybranych zastosowań, takich jak natywne przesyłanie wiadomości, procesy robocze usługi rozszerzeń będą aktywne dłużej niż 5 minut.

P: Czy w usługach Service Worker można uzyskać dostęp do DOM?
O: Stosujemy podejście przyjęte przez platformę internetową, które polega na tym, że w przypadku procesów roboczych w internecie (w tym service workerów) nie uwzględniamy dostępu do DOM. Aby obsługiwać przypadki użycia wymagające dostępu do DOM w tle ze skryptów service worker, wprowadziliśmy możliwość delegowania pracy w tle do krótkotrwałych dokumentów poza ekranem, które zapewniają pełny dostęp do DOM.

P: Czy będzie można obsługiwać kod zdalny na platformie Manifest V3?
O: Aby zwiększyć bezpieczeństwo rozszerzeń Chrome, nadal będziemy blokować wykonywanie w nich dowolnego kodu hostowanego zdalnie. Nie oznacza to jednak, że zabraniamy wszelkiego rodzaju dynamicznego wykonywania kodu. Nadal obsługujemy różne opcje dynamicznego wykonywania kodu w rozszerzeniach do Chrome:

P: Moje rozszerzenie Manifest V2 korzysta z funkcji webRequestBlocking, która nie jest obsługiwana w Manifest V3. Jak mogę nadal udostępniać te same funkcje na platformie Manifest V3?
O: Jesteśmy przekonani, że większość przypadków użycia blokowania żądań można rozwiązać za pomocą nowego declarativeNetRequest interfejsu API, który ma dodatkową zaletę, ponieważ pozwala uniknąć obciążenia wydajności związanego z komunikacją międzyprocesową, wykonywaniem kodu przy każdym żądaniu lub wymaganiem aktywnego procesu rozszerzenia w momencie żądania. W przypadku złożonych zastosowań w firmach (lub szkołach) dynamiczne blokowanie żądań jest nadal obsługiwane.

Czy coś pominęliśmy? Daj nam znać.