Firefox: Mozilla macht große Fortschritte mit WebExtensions
Während Firefox bereits einige WebExtensions-APIs unterstützt, soll Firefox 48 den offiziellen Start für die neue Add-on-Schnittstelle markieren. In den letzten Monaten hat sich diesbezüglich einiges getan, darunter mehr unterstützte APIs, Vorteile gegenüber klassischen Firefox-Erweiterungen, verbesserte Portabilität von Chrome, Verbesserungen für Erweiterungs-Entwickler und die Unterstützung von WebExtensions in Firefox für Android.
Am 2. August soll Firefox 48 erscheinen. Firefox 48 wird die Firefox-Version sein, in welcher die WebExtensions den Beta-Status verlassen. Mit Firefox 48 erscheint also die erste stabile Version der neuen Schnittstelle für Add-ons. Wie bereits zu den vorherigen Versionen hat Mozilla auch zum Status der WebExtensions in Firefox 48 einen Statusbericht veröffentlicht.
Neue APIs implementiert
Alleine gegenüber Firefox 47 wurden 81 Tickets bezüglich WebExtensions in Mozillas Bugtracker geschlossen. Die folgenden APIs wurden verbessert: alarms, bookmarks, downloads, notifications, webNavigation, webRequest, windows sowie tabs. Außerdem wird die options v2-API zur Umsetzung von Einstellungen nun unterstützt.
Besonders die webRequest-API war ein Fokus für Firefox 48, welche für Privatsphäre- und Sicherheits-Add-ons wie Ghostery, RequestPolicy und NoScript interessant ist und es mittlerweile ermöglichte, Ghostery als WebExtension für Firefox zu umzusetzen.
Mit dem Hinzufügen der request origin-Eigenschaft zeigt Mozilla, dass, obwohl die WebExtensions stark am Erweiterungssystem von Chrome angelehnt sind, Chrome nicht vorgibt, was Erweiterungen in Firefox tun können und was nicht, denn es handelt sich dabei um die erste Erweiterung über das hinaus, was Chrome anbietet.
Weiteres Highlight: die Unterstützung von requestBody in onBeforeRequest. Diese Zugabe erlaubt es dem XSS-Filter der populären NoScript-Erweiterung in bestimmten Situationen mehr als 20 mal so schnell zu sein wie in der XUL-Erweiterung.
Verbesserte Portabilität von Chrome
Dank einer Änderung in Firefox 48 können Add-ons ohne angegebene Add-on-ID im Manifest ausgeführt werden, was bedeutet, dass Chrome-Erweiterungen vollkommen ohne Manifest-Änderung in Firefox genutzt werden können (natürlich vorausgesetzt, dass Firefox die genutzten APIs unterstützt), was die Portierung von Chrome-Erweiterungen noch einfacher macht.
WebExtensions in Firefox für Android
Mit Firefox 48 für Android unterstützt erstmals auch die Android-Version von Firefox WebExtensions. Was Interaktionen mit der Benutzeroberfläche einschließt, wird bislang allerdings nicht unterstützt.
Verbesserungen für Entwickler
In Firefox 45 wurde about:debugging zum temporären Laden von Add-ons eingeführt, was das Testen während der Entwicklung vereinfacht. In Firefox 48 gab es diverse Verbesserungen. So wird hier nun eine Fehlermeldung angezeigt, wenn es Probleme beim Laden einer Erweiterung gibt. Außerdem ist nun auch das Debugging von Background- und Content-Scripts möglich.
Darüber hinaus ist es nicht länger notwendig, das Add-on nach jeder Änderung neu hinzuzufügen. Stattdessen gibt es nun eine Schaltfläche zum Neuladen. Das kürzlich vorgestellte Kommandozeilen-Werkzeug web-ext wird in Kürze die Möglichkeit erhalten, das Add-on automatisch bei jeder Dateiänderung neu zu laden.
Weitere aktuelle Artikel aus der Kategorie „Firefox“
- 09.10.2024Sicherheits-Update Firefox 131.0.2 veröffentlicht
- 24.09.2024Neue Sprachen für Übersetzungsfunktion von Firefox
- 23.09.2024Firefox 132: Tabs auf anderen Geräten schließen
- 22.09.2024Neue Hoffnung für Unterstützung von Bildformat JPEG-XL (JXL) in Firefox und Chrome
- 17.09.2024Mozilla veröffentlicht Firefox 130.0.1
Das sind doch gute Neuigkeiten.
Weiß jemand etwas dazu, wie gewillt dazu / aktiv dabei Chrome ist, die API-Erweiterungen ebenfalls zu übernehmen? Oder werden diese vrs. FF-spezifisch bleiben?
Das weiß ich nicht. Ich weiß aber, dass es das Bestreben von Mozilla, Microsoft und Opera gibt, bestimmte Add-on-APIs zu standardisieren und die API, welche hier erweitert worden ist, gehört dazu. Eine Standardisierung erhöht unter Umständen die Wahrscheinlichkeit, dass das irgendwann alle Browser unterstützen. Ich hoffe es zumindest. Vorausgesetzt, diese Eigenschaft wird mit standardisiert. 😉