Bekannte Probleme bei der Migration zu Manifest V3

Vor Kurzem haben wir Änderungen am Zeitplan für die Einstellung von Manifest V2 angekündigt. Auch wenn wir fest an Manifest V3 gebunden sind, wissen wir, dass es noch mehr zu tun gibt.

  • Bevor wir einen neuen Zeitplan für die Einstellung angekündigt hatten, haben wir die priorisierten Lücken auf der Plattform geschlossen und die kritischen Fehler behoben, die auf dieser Seite dokumentiert wurden.
  • Wir haben Entwicklern Zeit für die Entwicklung gegeben, indem wir zwischen einer Ankündigung des Zeitplans und den ausstehenden Tests für die Einstellung der Unterstützung von Manifest V2 mindestens sechs Monate festgehalten haben.

Die Plattformlücke schließen

Wir möchten die folgenden Lücken schließen, bevor wir einen neuen Zeitplan für die Einstellung von Manifest V2 ankündigen:

Die Probleme wurden anhand des Feedbacks von Partnern, Fehlerberichten und Entwicklern ermittelt. Wir werden weiterhin daran arbeiten, die Stabilität und Gesamtleistung der Erweiterungsplattform zu verbessern.

Es gibt derzeit keine offenen Probleme, die als kritische Plattformlücke betrachtet werden.

Die folgenden Probleme wurden kürzlich behoben:

  1. Unterstützung von Dateiverarbeitung unter ChromeOS als Ersatz für chrome.fileBrowserHandler [Chrome 120]
  2. Unterstützung von Nutzerskripts:Mit der neuen userScripts API [Chrome 120] können Inhaltsskripte mit beliebigem Code registriert werden.
  3. Zusätzliche starke Service Worker-Keepalives bei bestimmten Vorgängen, die länger als fünf Minuten dauern.
    • In Chrome 116 für permissions.request(), desktopCapture.chooseDesktopMedia(), identity.launchWebAuthFlow() und management.uninstall() hinzugefügt.
    • In Chrome 118 für chrome.debugger hinzugefügt
  4. Erhöhen Sie die Anzahl der statischen und aktivierten Regelsätze für die deklarative Nettoanfrage (DNR). Aktivierte statische Regelsätze wurden von 10 auf 50 erhöht und die Gesamtzahl der statischen Regelsätze von 50 auf 100 erhöht [Chrome 120].
  5. Erweitern Sie die Funktion für nicht sichtbare Dokumente, um weitere Gründe für die Verwendung von nicht sichtbaren Dokumenten zu unterstützen. GEOLOCATION wurde in Chrome 116 hinzugefügt.
  6. Bessere Unterstützung für die chrome.tabCapture API [Chrome 116]:
    • Unterstützung beim Aufrufen von getMediaStreamId() über einen Service Worker.
    • Unterstützung für den Abruf einer MediaStream von einer Stream-ID in einem nicht sichtbaren Dokument.
  7. Die Lebensdauer der Service Worker verlängern, solange WebSocket-Verbindungen [Chrome 116] aktiv sind.

Häufig gestellte Fragen zu Manifest V3

F: Planen wir die Unterstützung hartnäckiger Service Worker?
A: Einer der Hauptgründe für die Migration von Hintergrundskripts zu Service Workern ist das speichereffizientere, ereignisgesteuerte Programmiermodell, das auf den flüchtigen Charakter von Service Workern beruht. Daher planen wir nicht, hartnäckige Service Worker zu unterstützen. Um den spezifischen Anforderungen von Erweiterungsentwicklern gerecht zu werden, werden wir jedoch weiterhin viele Verbesserungen an Service Workern vornehmen. Wichtig ist insbesondere:

  • Durch alle Erweiterungsereignisse und API-Aufrufe wird die Lebensdauer der Service Worker verlängert.
  • Ausgewählte Anwendungsfälle wie natives Messaging sorgen dafür, dass die Service Worker der Erweiterungen länger als 5 Minuten aktiv sind.

F: Kann ich auf das DOM in den Service Workern zugreifen?
Antwort:Wir folgen dem Ansatz der Webplattform, den DOM-Zugriff bei Web Workern (einschließlich Service Workern) nicht einzubeziehen. Um Anwendungsfälle zu unterstützen, die einen Hintergrund-DOM-Zugriff von Service Workern erfordern, haben wir die Möglichkeit eingeführt, Hintergrundarbeiten an kurzlebige Offscreen-Dokumente zu delegieren, die vollständigen DOM-Zugriff bieten.

F: Wird es eine Möglichkeit geben, in Manifest V3 Remote-Code zu unterstützen?
Antwort:Um Chrome-Erweiterungen noch sicherer zu machen, wird die Ausführung von beliebigem extern gehostetem Code in Chrome-Erweiterungen weiterhin nicht mehr zulässig sein. Dies bedeutet jedoch nicht, dass alle Arten der dynamischen Codeausführung unzulässig sind. Wir unterstützen weiterhin verschiedene Optionen zum dynamischen Ausführen von Code in Chrome-Erweiterungen:

F: Meine Manifest V2-Erweiterung basiert auf „webRequestBlocking“, das in Manifest V3 nicht unterstützt wird. Wie kann ich in Manifest V3 weiterhin die gleichen Funktionen anbieten?
Antwort:Wir sind überzeugt, dass die meisten Anwendungsfälle, die Anfragen blockieren, mit der neuen declarativeNetRequest API gelöst werden können. Sie hat den zusätzlichen Vorteil, dass der Leistungsaufwand bei der Kommunikation zwischen Prozessen, dem Ausführen von Code bei jeder Anfrage oder der Aktivierung eines aktiven Erweiterungsprozesses zum Zeitpunkt der Anfrage entfällt. Für komplexe Anwendungsfälle in Unternehmen (oder Bildungseinrichtungen) wird die dynamische Anfrageblockierung jedoch weiterhin unterstützt.

Haben wir etwas übersehen? Bitte melde dich bei uns.