Erweiterungsaktionen in Manifest V3

Vincent
Simeon Vincent

Seit der Einführung von Chrome-Erweiterungen können Entwickler über die Plattform mithilfe von Aktionen die Funktionen von Erweiterungen direkt in der Chrome-Benutzeroberfläche auf oberster Ebene bereitstellen. Eine Aktion ist eine Symbolschaltfläche, über die ein Pop-up geöffnet oder Funktionen der Erweiterung ausgelöst werden. In der Vergangenheit unterstützte Chrome zwei Arten von Aktionen: Browseraktionen und Seitenaktionen. Mit Manifest V3 wurde die Funktionalität in einer neuen chrome.action API konsolidiert.

Kurzer Überblick über Erweiterungsaktionen

chrome.action ist zwar neu in Manifest V3, die grundlegenden Funktionen stammen aber aus der Zeit, als die Erweiterungen im Januar 2010 in der stabilen Version eingeführt wurden. Die erste stabile Version der Erweiterungsplattform von Chrome unterstützte zwei verschiedene Arten von Aktionen: Browseraktionen und Seitenaktionen.

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

In der Omnibox wird eine Seitenaktion (links) angezeigt, die darauf hinweist, dass die Erweiterung auf dieser Seite Aktionen ausführen kann. Eine Browseraktion (rechts) ist immer sichtbar.

Mit anderen Worten, Browseraktionen gaben Entwicklern von Erweiterungen eine dauerhafte Benutzeroberfläche im Browser, während Seitenaktionen nur angezeigt wurden, wenn die Erweiterung auf der aktuellen Seite etwas Nützliches tun konnte.

Beide Aktionstypen waren optional. Der Entwickler einer Erweiterung konnte also entweder keine Aktionen, eine Seitenaktion oder eine Browseraktion auswählen. Die Angabe mehrerer Aktionen ist nicht zulässig.

Ungefähr 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 hatten, werden in Chrome alle aktiven Erweiterungen rechts neben der Omnibox angezeigt. Nutzer konnten bei Bedarf Erweiterungen in das Chrome-Menü „überlaufen“.

Ausgeblendete Erweiterungssymbole würden dann im Chrome-Menü angezeigt.

Damit für jede Erweiterung ein Symbol angezeigt werden kann, wurden durch diese Aktualisierung zwei wichtige Änderungen am Verhalten von Erweiterungen auf der Benutzeroberfläche von Chrome vorgenommen. Zunächst wurden bei allen Erweiterungen Symbole in der Symbolleiste angezeigt. Wenn die Erweiterung kein Symbol hätte, generiert Chrome automatisch eines. Zweitens wurden Seitenaktionen neben Browseraktionen in die Symbolleiste verschoben und erhielten die Möglichkeit, zwischen den Status „Anzeigen“ und „Ausblenden“ zu unterscheiden.

Bei einer deaktivierten Seitenaktion (links) wird in der Symbolleiste ein Graustufenbild gerendert, während eine aktivierte Seitenaktion (rechts) in Farbe erscheint.

Durch diese Änderung konnten Seitenaktionserweiterungen weiterhin wie erwartet funktionieren, aber die Rolle von Seitenaktionen hat im Laufe der Zeit abgenommen. Durch die Neugestaltung der Benutzeroberfläche wurden unter anderem Seitenaktionen effektiv durch Browseraktionen zusammengefasst. Da alle Erweiterungen in der Symbolleiste angezeigt wurden, waren Nutzer davon überzeugt, dass ein Klick auf das Symbol der Erweiterung in der Symbolleiste die Erweiterung aufrufen würde. Browseraktionen werden für Chrome-Erweiterungen daher zu einer immer wichtigeren Interaktion.

Änderungen bei Manifest V3

Die Chrome-Benutzeroberfläche und die Chrome-Erweiterungen wurden in den Jahren nach der Neugestaltung der Erweiterung im Jahr 2016 weiterentwickelt. Browseraktionen und Seitenaktionen blieben jedoch weitgehend unverändert. Zumindest so lange, bis wir mit der Planung zur Modernisierung der Erweiterungsplattform mit Manifest V3 begonnen haben.

Dem Erweiterungsteam war klar, dass Browseraktionen und Seitenaktionen immer mehr Bedeutung haben. Schlimmer noch, es waren subtile Verhaltensunterschiede erforderlich, wodurch Entwickler sich nur schwer entscheiden konnten, welches sie verwenden sollten. Wir konnten diese Probleme lösen, indem wir die Browser- und Seitenaktion in einer einzigen "Aktion" kombinieren.

Geben Sie die Action API ein. chrome.action entspricht chrome.browserAction am ehesten, hat aber einige wesentliche Unterschiede.

Mit chrome.action wird eine neue Methode mit dem Namen getUserSettings() eingeführt. Mit dieser Methode können Entwickler von Erweiterungen prüfen, ob der Nutzer die Aktion der 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 „isPinned“ etwas ungewöhnlich erscheinen, aber der Verlauf der Aktionen in Chrome zeigt, dass sich die Browser-Benutzeroberfläche schneller ändert als Erweiterungs-APIs. Daher ist es mit dieser API das Ziel, aktionsbezogene Nutzereinstellungen auf generischen Schnittstellen verfügbar zu machen, um die zukünftige API-Abwanderung zu minimieren. Außerdem können andere Browseranbieter browserspezifische UI-Konzepte im UserSettings-Objekt bereitstellen, das von dieser Methode zurückgegeben wird.

Zweitens können das Symbol und der Aktivierungs-/Deaktivierungsstatus der Aktion einer Erweiterung mithilfe der Deklarative Content API gesteuert werden. Dies ist wichtig, weil Erweiterungen so auf das Browserverhalten des Nutzers reagieren können, ohne auf Inhalte oder die URLs der besuchten Seiten zuzugreifen. Sehen wir uns zum Beispiel an, wie eine Erweiterung ihre Aktion aktivieren kann, wenn der Nutzer Seiten von 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 bei einer Seitenaktion tun würde. Der einzige Unterschied besteht darin, dass wir in Manifest V3 declarativeContent.ShowAction anstelle von declarativeContent.ShowPageAction in Manifest V2 verwendet haben.

Inhaltsblocker können schließlich die Methode setExtensionActionOptions der deklarativenNetRequest API verwenden, um die Anzahl der Anfragen anzuzeigen, die von der Erweiterung für einen bestimmten Tab blockiert wurden. Diese Funktion ist wichtig, da Inhaltsblocker Endnutzer auf dem Laufenden halten können, ohne potenziell vertrauliche Browsermetadaten der Erweiterung preiszugeben.

Zusammenfassung

Die Modernisierung der Plattform für Chrome-Erweiterungen war einer unserer Hauptmotivationen für Manifest V3. In vielen Fällen bedeutete dies, zu neuen Technologien zu wechseln, aber es bedeutete auch, unsere API-Oberfläche zu vereinfachen. Genau das war unser Ziel.

Ich hoffe, dass ich dir mit diesem Post etwas über diesen Aspekt der Manifest V3-Plattform erzählen konnte. Wenn Sie mehr darüber erfahren möchten, wie das Chrome-Team die Zukunft von Browsererweiterungen annimmt, sehen Sie sich die Seiten zur Vision der Plattform und Übersicht über Manifest V3 in unserer Entwicklerdokumentation an. Sie können sich auch mit anderen Entwicklern in der Google-Gruppe chromium-extensions über Chrome-Erweiterungen austauschen.