Erweiterungsaktionen in Manifest V3

Simeon Vincent
Simeon Vincent

Seit der Einführung von Chrome-Erweiterungen können Entwickler mit Aktionen Erweiterungsfunktionen direkt in der Chrome-Benutzeroberfläche der obersten Ebene verfügbar machen. Eine Aktion ist eine Symbolschaltfläche, mit der ein Pop-up-Fenster geöffnet oder eine Funktion in der Erweiterung ausgelöst werden kann. Bisher unterstützte Chrome zwei Arten von Aktionen: Browseraktionen und Seitenaktionen. Mit Manifest V3 wurde dies geändert, indem die Funktionalität in einer neuen chrome.action-API zusammengefasst wurde.

Kurzer Überblick über Erweiterungsaktionen

chrome.action ist zwar neu in Manifest V3, die grundlegende Funktionalität, die es bietet, stammt jedoch aus der Zeit, als Erweiterungen im Januar 2010 erstmals in der stabilen Version verfügbar waren. Die erste stabile Version der Chrome-Erweiterungsplattform unterstützte zwei verschiedene Arten von Aktionen: Browseraktionen und Seitenaktionen.

Mit Browseraktionen konnten Erweiterungsentwickler ein Symbol „in der Hauptsymbolleiste von Google Chrome rechts neben der Adressleiste“ (Quelle) anzeigen und Nutzern eine einfache Möglichkeit bieten, die Erweiterungsfunktionen auf jeder Seite auszulösen. Seitenaktionen hingegen sollten „Aktionen darstellen, die auf der aktuellen Seite ausgeführt werden können, aber nicht für alle Seiten gelten“ (Quelle).

Im Omnibox wird eine Seitenaktion (links) angezeigt, die darauf hinweist, dass die Erweiterung auf dieser Seite etwas tun kann. Eine Browseraktion (rechts) ist immer sichtbar.

Mit anderen Worten: Browseraktionen boten Erweiterungsentwicklern eine dauerhafte UI-Oberfläche im Browser, während Seitenaktionen nur angezeigt wurden, wenn die Erweiterung auf der aktuellen Seite etwas Nützliches tun konnte.

Beide Arten von Aktionen waren optional. Ein Erweiterungsentwickler konnte also entweder keine Aktionen, eine Seitenaktion oder eine Browseraktion bereitstellen. Die Angabe mehrerer Aktionen war nicht zulässig.

Etwa sechs Jahre später wurde mit Chrome 49 ein neues UI-Paradigma für Erweiterungen eingeführt. Damit Nutzer besser nachvollziehen können, welche Erweiterungen sie installiert haben, werden in Chrome alle aktiven Erweiterungen rechts neben der Omnibox angezeigt. Nutzer konnten Erweiterungen bei Bedarf in das Chrome-Menü „überlaufen“ lassen.

Ausgeblendete Erweiterungssymbole werden im Chrome-Menü angezeigt.

Damit für jede Erweiterung ein Symbol angezeigt werden kann, wurden mit diesem Update auch zwei wichtige Änderungen an der Funktionsweise von Erweiterungen in der Chrome-Benutzeroberfläche eingeführt. Zuerst wurde für alle Erweiterungen ein Symbol in der Symbolleiste angezeigt. Wenn die Erweiterung kein Symbol hatte, wurde in Chrome automatisch eines generiert. Zweitens wurden Seitenaktionen in die Symbolleiste neben Browseraktionen verschoben und es wurde eine Möglichkeit geschaffen, zwischen den Status „Einblenden“ und „Ausblenden“ zu unterscheiden.

Eine deaktivierte Seitenaktion (links) wird in der Symbolleiste als Graustufenbild gerendert, während eine aktivierte Seitenaktion (rechts) in voller Farbe angezeigt wird.

Durch diese Änderung konnten Erweiterungen für Seitenaktionen weiterhin wie erwartet funktionieren. Die Rolle von Seitenaktionen wurde jedoch im Laufe der Zeit verringert. Eine der Auswirkungen der Neugestaltung der Benutzeroberfläche war, dass Seitenaktionen effektiv in Browseraktionen aufgegangen sind. Da alle Erweiterungen in der Symbolleiste angezeigt wurden, erwarteten die Nutzer, dass durch Klicken auf das Symbol einer Erweiterung in der Symbolleiste die Erweiterung aufgerufen wird. Browseraktionen wurden daher zu einer immer wichtigeren Interaktion für Chrome-Erweiterungen.

Änderungen in Manifest V3

Die Chrome-Benutzeroberfläche und die Erweiterungen haben sich in den Jahren nach der Neugestaltung der Erweiterungs-Benutzeroberfläche im Jahr 2016 weiterentwickelt, aber Browser- und Seitenaktionen blieben weitgehend unverändert. Das war zumindest so, bis wir mit der Planung der Modernisierung der Erweiterungsplattform mit Manifest V3 begonnen haben.

Dem Erweiterungsteam war klar, dass Browser- und Seitenaktionen zunehmend eine Unterscheidung ohne Bedeutung waren. Außerdem war es für Entwickler aufgrund der geringfügigen Verhaltensunterschiede schwierig, sich für eine der beiden APIs zu entscheiden. Wir haben festgestellt, dass wir diese Probleme beheben können, indem wir die Browseraktion und die Seitenaktion in einer einzigen „Aktion“ zusammenfassen.

Geben Sie die Action API ein. chrome.action ist am ehesten mit chrome.browserAction vergleichbar, es gibt jedoch einige wichtige Unterschiede.

Zuerst wird in chrome.action eine neue Methode namens getUserSettings() eingeführt. Mit dieser Methode können Erweiterungsentwickler prüfen, ob der Nutzer die Aktion ihrer Erweiterung an die Symbolleiste angepinnt hat.

let userSettings = await chrome.action.getUserSettings();
console.log(`Is the action pinned? ${userSettings.isOnToolbar ? 'Yes' : 'No'}.`);

„getUserSettings“ mag im Vergleich zu beispielsweise „isPinned“ ein etwas ungewöhnlicher Name für diese Funktion sein, aber der Verlauf der Aktionen in Chrome zeigt, dass sich die Browser-UI schneller ändert als Erweiterungs-APIs. Daher ist es unser Ziel, mit dieser API aktionsbezogene Nutzereinstellungen über generische Schnittstellen verfügbar zu machen, um zukünftige API-Änderungen zu minimieren. Außerdem können andere Browseranbieter browserspezifische UI-Konzepte im UserSettings-Objekt verfügbar machen, das von dieser Methode zurückgegeben wird.

Zweitens können das Symbol und der aktivierte/deaktivierte Status einer Erweiterungsaktion über die Declarative Content API gesteuert werden. Das ist wichtig, weil Erweiterungen so auf das Surfverhalten des Nutzers reagieren können, ohne auf die Inhalte oder URLs der besuchten Seiten zuzugreifen. Sehen wir uns beispielsweise an, wie eine Erweiterung ihre Aktion aktivieren kann, wenn der Nutzer Seiten auf example.com besucht.

// Manifest V3
chrome.runtime.onInstalled.addListener(() => {
  chrome.declarativeContent.onPageChanged.removeRules(undefined, () => {
    chrome.declarativeContent.onPageChanged.addRules([
      {
        conditions: [
          new chrome.declarativeContent.PageStateMatcher({
            pageUrl: {hostSuffix: '.example.com'},
          })
        ],
        actions: [new chrome.declarativeContent.ShowAction()]
      }
    ]);
  });
});

Der obige Code ist fast identisch mit dem, was eine Erweiterung mit einer Seitenaktion tun würde. Der einzige Unterschied besteht darin, dass in Manifest V3 declarativeContent.ShowAction anstelle von declarativeContent.ShowPageAction in Manifest V2 verwendet wurde.

Schließlich können Contentblocker mit der Methode setExtensionActionOptions der declarativeNetRequest API die Anzahl der Anfragen anzeigen, die von der Erweiterung für einen bestimmten Tab blockiert wurden. Diese Funktion ist wichtig, da sie es Content-Blockern ermöglicht, Endnutzer auf dem Laufenden zu halten, ohne potenziell vertrauliche Browsing-Metadaten für die Erweiterung preiszugeben.

Zusammenfassung

Die Modernisierung der Chrome-Erweiterungsplattform war einer unserer Hauptgründe für Manifest V3. In vielen Fällen bedeutete das, auf neue Technologien umzusteigen, aber auch, unsere API-Oberfläche zu vereinfachen. Das war unser Ziel.

Ich hoffe, dass dieser Beitrag etwas Licht in diesen speziellen Bereich der Manifest V3-Plattform gebracht hat. Weitere Informationen dazu, wie das Chrome-Team die Zukunft von Browsererweiterungen angeht, finden Sie in unserer Entwicklerdokumentation auf den Seiten Platform vision und Overview of Manifest V3. Sie können sich auch mit anderen Entwicklern in der Google-Gruppe chromium-extensions über Chrome-Erweiterungen austauschen.