Firefox-Add-on erstellen und bei addons.mozilla.org einreichen

Ein Firefox-Add-on erstellen Sie nach demselben WebExtensions-Modell wie eine Chrome-Erweiterung: ein Ordner mit manifest.json, JavaScript und HTML. Firefox-spezifisch sind die Add-on-ID im Manifest, der Hintergrund über background.scripts und die Signierung durch Mozilla. Veröffentlicht wird kostenlos über addons.mozilla.org (AMO), lokal testen Sie über about:debugging oder das Kommandozeilenwerkzeug web-ext.

Was bei Firefox anders ist

Wer schon eine Chrome-Erweiterung gebaut hat, kennt das meiste. Die Unterschiede liegen im Detail:

Eine Gegenüberstellung der Manifest-Versionen finden Sie im Beitrag Manifest V2 vs. V3.

Das Manifest für Firefox

Ein minimales Manifest V3 für Firefox sieht so aus:

{
  "manifest_version": 3,
  "name": "Tab-Notizen",
  "version": "1.0.0",
  "description": "Speichert eine kurze Notiz zur aktuell geöffneten Seite.",
  "action": { "default_popup": "popup.html" },
  "background": { "scripts": ["background.js"] },
  "permissions": ["storage", "activeTab"],
  "browser_specific_settings": {
    "gecko": {
      "id": "tab-notizen@example.org",
      "data_collection_permissions": { "required": ["none"] }
    }
  }
}

Wichtig sind zwei Schlüssel unter browser_specific_settings.gecko:

• id: Die Add-on-ID identifiziert Ihr Add-on dauerhaft. Unter Manifest V3 ist sie für die Signierung erforderlich. Üblich ist ein Format wie eine E-Mail-Adresse mit einer Domain, die Sie kontrollieren, oder eine GUID in geschweiften Klammern. Ändern Sie die ID nach der Veröffentlichung nicht mehr, sonst entsteht ein neues Add-on.
• data_collection_permissions: Mozilla verlangt von neuen Add-ons eine Angabe, ob und welche Daten erhoben und übertragen werden. Firefox zeigt diese Angaben bei der Installation an. Ein Add-on, das nichts überträgt, deklariert "none".

Soll dieselbe Codebasis auch in Chrome laufen, können Sie unter background sowohl scripts als auch service_worker angeben. Firefox nutzt dann die Skripte, Chrome den Service Worker. Alternativ erzeugt ein Build-Schritt je Browser ein eigenes Manifest.

Code: browser oder chrome?

Firefox stellt die APIs unter browser.* bereit und liefert dort Promises zurück. Der Namensraum chrome.* funktioniert zur Kompatibilität ebenfalls. Ein kleiner Hintergrund-Code für das Beispiel:

// background.js
browser.runtime.onMessage.addListener((nachricht) => {
  if (nachricht.typ === "notiz-speichern") {
    return browser.storage.local
      .set({ [nachricht.url]: nachricht.text })
      .then(() => ({ ok: true }));
  }
  // andere Nachrichten: nichts zurückgeben
});

In Firefox darf ein onMessage-Listener ein Promise zurückgeben, dessen Wert als Antwort ankommt. Wer auch Chrome bedient, prüft dieses Verhalten dort gesondert oder nutzt das Polyfill von Mozilla, das die Unterschiede glättet.

Eine Codebasis für Firefox und Chrome

Die meisten Projekte bedienen beide Browser aus einem Quellordner. Drei Wege haben sich bewährt:

• Ein gemeinsames Manifest: Unter background stehen sowohl scripts als auch service_worker, und browser_specific_settings wird von Chrome ignoriert. Das ist der einfachste Weg, solange sich die Browser nur wenig unterscheiden.
• Ein Build-Schritt mit zwei Manifesten: Ein Skript erzeugt aus einer Vorlage je Browser ein eigenes Manifest und kopiert den Code in zwei Ausgabeordner. Das ist sauberer, sobald Berechtigungen oder Einstiegspunkte voneinander abweichen.
• Ein Erweiterungs-Framework: Werkzeuge, die auf Vite oder ähnlichen Bundlern aufsetzen, erzeugen die Pakete für mehrere Browser automatisch und übernehmen das Neuladen beim Entwickeln.

Unabhängig vom Weg gilt: Prüfen Sie vor dem Aufruf einer API, ob sie existiert, statt den Browser zu erkennen. Ein Ausdruck wie globalThis.browser ?? globalThis.chrome liefert in beiden Browsern einen nutzbaren Namensraum. Halten Sie außerdem die Versionsnummer für beide Pakete synchron, damit Fehlermeldungen von Nutzern eindeutig einer Version zugeordnet werden können.

Lokal testen

Über about:debugging

1. Öffnen Sie about:debugging und wählen Sie „Dieser Firefox“.
2. Klicken Sie auf „Temporäres Add-on laden“ und wählen Sie die manifest.json.
3. Über „Untersuchen“ öffnen Sie die Entwicklerwerkzeuge für den Hintergrund des Add-ons.

Temporäre Add-ons verschwinden beim Neustart von Firefox. Für den Alltag ist deshalb web-ext bequemer.

Mit web-ext

web-ext ist ein Kommandozeilenwerkzeug von Mozilla, das über npm installiert wird. Es startet Firefox mit Ihrem Add-on in einem frischen Profil und lädt es bei jeder Dateiänderung automatisch neu.

npm install --global web-ext

web-ext run        # Firefox mit dem Add-on starten
web-ext lint       # Manifest und Code prüfen wie bei AMO
web-ext build      # ZIP-Paket für die Einreichung erzeugen

web-ext lint nutzt dieselben Prüfregeln wie die automatische Validierung auf AMO. Fehler, die hier auftauchen, sollten Sie vor der Einreichung beheben. Das spart Runden mit abgelehnten Uploads.

Einreichen bei addons.mozilla.org

1. Konto anlegen: Melden Sie sich mit einem Mozilla-Konto im Developer Hub auf addons.mozilla.org an und akzeptieren Sie die Vereinbarung für Entwickler.
2. Vertriebsweg wählen: „Auf dieser Website“ (gelistet) für den öffentlichen Katalog oder „Selbst verteilen“ (unlisted), wenn Sie die signierte Datei selbst anbieten.
3. Paket hochladen: Laden Sie das ZIP aus web-ext build hoch. AMO validiert es automatisch und zeigt Fehler und Warnungen.
4. Quellcode beifügen, falls nötig: Wenn Ihr Paket gebündelten, minifizierten oder generierten Code enthält, verlangt Mozilla den Originalquellcode und eine Bauanleitung, mit der Prüfer das Paket nachbauen können.
5. Angaben ausfüllen: Name, Zusammenfassung, Beschreibung, Kategorien, Screenshots, Support-Kontakt, Datenschutzerklärung bei Datenverarbeitung und eine Lizenz.
6. Absenden: Nach bestandener automatischer Prüfung wird das Add-on signiert. Gelistete Add-ons können zusätzlich manuell geprüft werden, auch nach der Veröffentlichung.

Bei der Lizenz fragt AMO ausdrücklich nach. Welche Lizenz zu welchem Ziel passt, beschreibt der Beitrag Open-Source-Lizenz für Plugins wählen.

Signieren per Kommandozeile

Für automatisierte Abläufe, etwa in einer CI-Pipeline, kann web-ext sign das Paket direkt an AMO senden. Dazu erzeugen Sie im Developer Hub einen API-Schlüssel mit zugehörigem Geheimnis und übergeben beides als Parameter oder Umgebungsvariablen. Mit dem Kanal unlisted erhalten Sie eine signierte Datei zur Selbstverteilung, mit listed reichen Sie eine neue Version für den Katalog ein. Behandeln Sie die Schlüssel wie Passwörter und legen Sie sie niemals im Repository ab.

Checkliste vor dem ersten Upload

• browser_specific_settings.gecko.id gesetzt und endgültig gewählt
• Angaben zur Datenerhebung vollständig und passend zum tatsächlichen Verhalten
• web-ext lint ohne Fehler, Warnungen gelesen und bewertet
• Nur Berechtigungen im Manifest, die der Code wirklich nutzt
• Kein Code, der von fremden Servern nachgeladen und ausgeführt wird
• Bei gebündeltem Code: Quellcode-Archiv und kurze Bauanleitung bereit
• Symbol, aussagekräftige Beschreibung und mindestens ein Screenshot vorbereitet
• Lizenz festgelegt und Datenschutzerklärung vorhanden, falls Daten verarbeitet werden
• Versionsnummer höher als die zuletzt hochgeladene

Wer diese Punkte vorab abhakt, erspart sich die meisten Rückfragen aus der Prüfung. Vor allem die Bauanleitung wird oft unterschätzt: Prüfer müssen aus Ihrem Quellcode exakt dasselbe Paket erzeugen können, das Sie hochgeladen haben.

Prüfung und typische Probleme

Prüfer achten besonders darauf, dass der Code nachvollziehbar ist, keine Daten ohne Zustimmung überträgt und keine fremden Inhalte unsicher in Seiten einfügt. Verschleierter Code ist nicht erlaubt.

Firefox für Android

Firefox für Android unterstützt Erweiterungen ebenfalls. Damit Ihr Add-on dort angeboten wird, markieren Sie es bei AMO als kompatibel mit Android und testen es vorab, etwa mit web-ext run --target=firefox-android und einem per USB verbundenen Gerät. Nicht jede API steht auf Android zur Verfügung, und Popups verhalten sich auf kleinen Bildschirmen anders.

Nach der Veröffentlichung

Jede neue Version braucht eine höhere Versionsnummer und durchläuft erneut Validierung und Signierung. Firefox aktualisiert Add-ons automatisch. Neue Berechtigungen lösen dabei eine Rückfrage bei Nutzern aus, was erfahrungsgemäß zu Abbrüchen führt. Fordern Sie Rechte deshalb so früh wie nötig, aber so sparsam wie möglich an, oder nutzen Sie optional_permissions, die erst bei Bedarf abgefragt werden. Wie Sie Versionen, Changelog und Pflege organisieren, behandelt der Bereich Add-ons veröffentlichen und pflegen.