Nicht sichtbare Dokumente in Manifest V3

Ian Stanion
Ian Stanion

Entwickler können die chrome.offscreen API und Manifestberechtigung ab Chrome 109 verwenden, um Funktionen bei der Umstellung von Hintergrundseiten auf Erweiterungs-Service-Worker zu ersetzen. Wenn Sie diese Berechtigung anfordern, können Dokumente außerhalb des Bildschirms erstellt werden, um DOM-APIs zu verwenden, ohne aufdringlich neue Fenster oder Tabs öffnen zu müssen, die den Nutzer stören. Die chrome.offscreen API ist jetzt in Chrome-Erweiterungen verfügbar.

In Chromium basieren Manifest V3-Erweiterungen auf Service Workern. Service Worker unterstützen jedoch nicht dieselben APIs und Mechanismen wie vollständige dokumentenbasierte Seiten (einschließlich Hintergrund- und Ereignisseiten). Außerdem unterliegen Inhaltsskripts für den Zugriff auf DOM APIs auf Webseiten der Erweiterung unterschiedlicher Content Security Policy-Richtlinien auf Seitenebene. Um dieses Problem zu lösen, führen wir „Offscreen Documents“ ein, um DOM-bezogene Funktionen und APIs zu unterstützen. Mit Manifest V3-Erweiterungen können zur Laufzeit minimale, beschränkte und relativ nicht berechtigte Dokumente außerhalb des Bildschirms über eine dedizierte API geöffnet werden.

Informationen zur Funktion

Da nicht sichtbare Dokumente speziell für Anwendungsfälle entwickelt wurden, die von Service Workern nicht unterstützt werden (z. B. Audiowiedergabe), unterscheiden sich die Lebensdauer dieser Seite und die gewährten Berechtigungen von denen des Extension Service Workers. Die Seite hat einen Mechanismus für die gesamte Lebensdauer, ähnlich wie Ereignisseiten in Manifest V2, dass sie entfernt wird, wenn sie keine Aktionen mehr ausführt. Darüber hinaus kann der User-Agent die Lebensdauer für den angegebenen Zweck weiter einschränken. Nicht sichtbare Dokumente sollen Lücken in APIs schließen, die nur für DOM-APIs zugänglich sind. Aus diesem Grund müssen Erweiterungs-APIs in diesem Kontext nicht direkt bereitgestellt werden. Um die Wahrscheinlichkeit zu verringern, dass Erweiterungen diese als „Hintergrundseitenersatz“ verwenden, werden nur die chrome.runtime Messaging-APIs für das nicht sichtbare Dokument freigegeben. Entwickler können Web-Messaging auch nutzen, indem sie über ihren Service Worker Anspruch auf das nicht sichtbare Dokument als Client erheben. Da für einige Anwendungsfälle – insbesondere Website Scraping – Zugriff auf ursprungsübergreifende Frames erforderlich ist, lassen wir diese Dokumente zu, um ursprungsübergreifende Frames einzubetten. Dabei gelten dieselben Regeln wie bei Erweiterungsseiten. In nicht sichtbaren Dokumenten können die von der Erweiterung vorgegebenen Inhaltsskripte in diesen Frames ausgeführt werden, um den erforderlichen Inhalt zu kopieren, wie es bei jeder normalen Webseite der Fall wäre.

Gründe und ein Zweck

Für die Erstellung eines nicht sichtbaren Dokuments sind Gründe und eine weitere Begründung erforderlich. Diese Gründe sind in der API-Referenzdokumentation aufgeführt. Die Lebensdauer des Dokuments wird unterschiedlich gehandhabt. So gelten beispielsweise für ein Dokument, das für die Audiowiedergabe geöffnet ist, andere Regeln für seine Lebensdauer als für ein Dokument, das für die Verwaltung der Zwischenablage geöffnet wird. Sie können in der Begründung auch weitere Details zum Zweck des nicht sichtbaren Dokuments hinzufügen. Dabei handelt es sich um einen vom Entwickler geschriebenen String und nicht um einen Parameter mit Auswirkungen auf das Dokument. Im Laufe der Zeit können der API weitere Gründe hinzugefügt werden, wenn Entwickler ihr Feedback und ihre Anwendungsfälle mitteilen.

Ab in die Zukunft

Um die Implementierung zu erleichtern, unterstützt die erste Version dieser API jeweils nur eine Seite pro Erweiterung und Profil. In zukünftigen Versionen werden wir diese Funktion möglicherweise lockern, um mehrere Seiten zu unterstützen. Wenn die Erweiterung im geteilten Modus mit einem aktiven Inkognitoprofil ausgeführt wird, kann derzeit sowohl das normale als auch das Inkognitoprofil ein nicht sichtbares Dokument enthalten. Außerdem ist geplant, dem Extension Worker die DOM-Funktionen zu einem späteren Zeitpunkt zur Verfügung zu stellen. Sie können Ihre Erweiterungen „zukunftssicher“ machen, indem Sie Funktionen, die die nicht sichtbare API verwenden, mit einer entsprechenden kommentierten Funktion im Service Worker koppeln, damit sie später ausgetauscht werden können.

// Solution 1 - Service workers cannot directly interact with
// the system clipboard. To work around this, we'll create an offscreen
// document and pass the data we want to write to the clipboard.
async function addToClipboard(value) {
    await chrome.offscreen.createDocument({
      url: 'offscreen.html',
      reasons: [chrome.offscreen.Reason.CLIPBOARD],
      justification: 'Write text to the clipboard.',
    });
  }


// Solution 2 – Once extension service workers can use the Clipboard API,
// replace the offscreen document based implementation with something like this
async function addToClipboardV2(value) {
  navigator.clipboard.writeText(value);
}

Wenn außerdem DOM-Funktionen und APIs zum Service Worker hinzugefügt werden, wird die Liste der Gründe für das Erstellen eines Dokuments abhängig vom aktuellen Status des Service Workers und den Gründen für die Verwendung von nicht sichtbaren Dokumenten hinzugefügt oder reduziert.

Fazit

Offline-Dokumente ermöglichen Erweiterungen, die einen DOM- oder Fenster-Interaktionszugriff erfordern, der für Service Worker derzeit nicht realisierbar ist. Es bietet auch einen flexiblen Ansatz, bei dem neue Anwendungsfälle hinzugefügt und in Zukunft gelöste Anwendungsfälle entfernt werden können. Erweiterungen sollten die vorgeschlagene API für nicht bildschirmfüllende Dokumente für bestimmte Anwendungsfälle verwenden. Der primäre Hintergrundkontext der Erweiterung sollte der im Manifest angegebene Service Worker bleiben. Das nicht sichtbare Dokument sollte nicht der Ort sein, an dem die primäre Erweiterungslogik gespeichert werden sollte, da es einen eingeschränkten API-Zugriff hat. Die Lebensdauer eines nicht sichtbaren Dokuments ist unabhängig vom Service Worker, der es erstellt hat. Überlegungen zur Service Worker-Lifetime und zu Anwendungsfällen in Bezug auf die Service Worker-Lifetime in Erweiterungen werden in einem separaten Blogpost behandelt. Die Gründe für die Verwendung nicht sichtbarer Dokumente ändern sich im Laufe der Zeit, da dem Service Worker Funktionen und APIs hinzugefügt werden. Wir sind schon jetzt auf Feedback von Entwicklern gespannt.

Foto von Kari Shea bei Unsplash