Auf dieser Seite werden die Plattformlücken dokumentiert, die während der Umstellung auf Manifest V3 geschlossen wurden, und es werden häufig gestellte Fragen zur Migration beantwortet.
Behobene Plattformlücken
Die folgenden Funktionen wurden hinzugefügt, um häufige Migrationsblocker zu beheben:
- Unterstützung für die Dateiverarbeitung unter ChromeOS als Ersatz für
chrome.fileBrowserHandler(Chrome 120). - Unterstützung von Nutzer-Scripts:Mit der neuen userScripts API (Chrome 120) können Content-Scripts mit beliebigem Code registriert werden.
- Zusätzliche starke Service Worker-Keepalives für bestimmte Vorgänge, die länger als fünf Minuten dauern.
- In Chrome 116 für
permissions.request(),desktopCapture.chooseDesktopMedia(),identity.launchWebAuthFlow()undmanagement.uninstall()hinzugefügt. - In Chrome 118 für
chrome.debuggerhinzugefügt.
- In Chrome 116 für
- Erhöhen Sie die Anzahl der statischen und aktivierten Regelsätze für Declarative Net Request (DNR). Die Anzahl der aktivierten statischen Regelsätze wurde von 10 auf 50 und die Gesamtzahl der statischen Regelsätze von 50 auf 100 erhöht (Chrome 120).
- Offscreen-Dokument-Funktionalität erweitern, um mehr Gründe für die Verwendung eines Offscreen-Dokuments zu unterstützen.
GEOLOCATIONwurde in Chrome 116 hinzugefügt. - Verbesserung der Unterstützung für die
chrome.tabCaptureAPI (Chrome 116):- Unterstützung für Anrufe an
getMediaStreamId()über einen Service Worker. - Unterstützung für das Abrufen einer
MediaStreamaus einer Stream-ID in einem Offscreen-Dokument.
- Unterstützung für Anrufe an
- Verlängerung der Lebensdauer von Service-Workern bei aktiven
WebSocket-Verbindungen (Chrome 116).
Häufig gestellte Fragen zu Manifest V3
F: Planen wir, persistente Service Worker zu unterstützen?
A:Einer der Hauptgründe für die Migration von Hintergrundskripts zu Service Workern ist das speichereffizientere ereignisgesteuerte Programmiermodell, das sich aus der Kurzlebigkeit von Service Workern ergibt. Daher planen wir nicht, persistente Service Worker zu unterstützen. Um den besonderen Anforderungen von Erweiterungsentwicklern gerecht zu werden, arbeiten wir jedoch weiterhin an vielen Verbesserungen für Service Worker. Wichtig ist insbesondere:
- Alle Erweiterungsereignisse und API-Aufrufe verlängern die Lebensdauer des Service Workers.
- Bei ausgewählten Anwendungsfällen wie dem nativen Messaging bleiben Service Worker von Erweiterungen länger als 5 Minuten aktiv.
F: Gibt es eine Möglichkeit, in Service Workern auf das DOM zuzugreifen?
A:Wir folgen dem Ansatz der Webplattform, DOM-Zugriff nicht in Webworkern (einschließlich Service Workern) zu ermöglichen. Um Anwendungsfälle zu unterstützen, die einen DOM-Zugriff im Hintergrund durch Service Worker erfordern, haben wir die Möglichkeit eingeführt, Hintergrundaufgaben an kurzlebige Offscreen-Dokumente zu delegieren, die vollen DOM-Zugriff bieten.
F: Wird es eine Möglichkeit geben, Remote-Code in Manifest V3 zu unterstützen?
A: Um Chrome-Erweiterungen sicherer zu machen, werden wir weiterhin die Ausführung von beliebigem remote gehosteten Code in Chrome-Erweiterungen untersagen. Das bedeutet jedoch nicht, dass wir alle Arten der dynamischen Code-Ausführung verbieten. Wir unterstützen weiterhin verschiedene Optionen zum dynamischen Ausführen von Code in Chrome-Erweiterungen:
- Unterstützung für
eval()in Entwicklertools-Erweiterungen - Unterstützung für Nutzer-Scripts.
- Ausführung von remote gehostetem Code in iFrames, die in einer Sandbox ausgeführt werden
- Remote gehostete Konfigurationsdateien, die zur Laufzeit im Erweiterungspaket interpretiert werden können. Mögliche Ausführungspfade müssen jedoch im Voraus festgelegt werden.
F: Meine Manifest V2-Erweiterung basiert auf „webRequestBlocking“, das in Manifest V3 nicht unterstützt wird. Wie kann ich in Manifest V3 weiterhin dieselben Funktionen anbieten?
A:Wir sind zuversichtlich, dass die meisten Anwendungsfälle für das Blockieren von Anfragen mit der neuen declarativeNetRequest API gelöst werden können. Sie bietet den zusätzlichen Vorteil, dass der Leistungsaufwand für die Interprozesskommunikation vermieden wird, Code bei jeder Anfrage ausgeführt wird oder zum Zeitpunkt der Anfrage ein aktiver Erweiterungsprozess erforderlich ist. Bei komplexen Anwendungsfällen für Unternehmen oder Bildungseinrichtungen wird das dynamische Blockieren von Anfragen jedoch weiterhin unterstützt.
Haben wir etwas übersehen? Bitte teilen Sie uns dies mit.