Firefox 57 mit exklusiver WebExtension-Unterstützung
Mozilla hat angekündigt, ab Firefox 57 nur noch WebExtensions als Erweiterungs-Architektur für Firefox zuzulassen. Erweiterungs-Entwickler sollten also ihre Erweiterungen, falls diese noch auf einer alten Architektur basieren, im Laufe des nächsten Jahres anpassen.
WebExtensions, erstmals im August 2015 angekündigt, sind der neue Standard für die Entwicklung von Erweiterungen für Firefox. Dass der Tag kommen wird, an dem in Firefox nur noch WebExtensions unterstützt werden, war seit dem klar, nun gibt es einen konkreten Zeitplan.
Nach aktueller Planung soll Firefox 57 die erste Version sein, welche ausschließlich WebExtensions unterstützt. Die Veröffentlichung von Firefox 57 ist derzeit für den 28. November 2017 geplant. Bereits ab Firefox 53 (geplante Veröffentlichung: 18. April 2017) sollen auf addons.mozilla.org keine neuen Erweiterungen mehr akzeptiert werden, welche keine WebExtensions sind. Bestehende Erweiterungen können bis Firefox 57 natürlich weiterhin vollkommen unabhängig von der Architektur aktualisiert werden. Wie immer und vor allem bei derart großen Veränderungen gilt, dass dies ein vorläufiger Zeitplan ist und Verzögerungen nicht ausgeschlossen werden können.
WebExtensions besitzen gegenüber alten Erweiterungs-Architekturen wie SDK- oder XUL-basierte Erweiterungen große Vorteile, werden aber teilweise kontrovers gesehen, weil WebExtensions nicht frei von Nachteilen sind. Der größte Knackpunkt hat gar nicht so viel mit den WebExtensions selbst zu tun, sondern viel mehr mit der Tatsache, dass bestehende Erweiterungen aktualisiert werden müssen, was je nach Erweiterung unter Umständen sogar eine Neuentwicklung der jeweiligen Erweiterung bedeuten kann, und niemand weiß, ob die Entwickler aller Erweiterungen, die man selbst nutzt, alle mitziehen werden. Ein weiterer Kritikpunkt besteht darin, dass der Funktionsumfang gegenüber den älteren Erweiterungssystemen limitiert ist.
Wichtig ist dabei, dass der Funktionsumfang von WebExtensions heute nicht dem Funktionsumfang von WebExtensions in einem Jahr entspricht. Mozilla ruht sich seit der Einführung der WebExtenions nicht aus und verbessert diese stetig und nichts anderes ist für die Zukunft geplant. Während der bisherige Fokus vor allem darauf lag, eine gemeinsame Kompatibilitäts-Basis mit Google Chrome zu schaffen, sollen im nächsten Jahr verstärkt Schnittstellen implementiert werden, welche in anderen Browsern nicht existieren – damit Firefox auch in Zukunft der am besten anpassbare Browser auf dem Markt bleibt.
Bei den genannten Einschränkungen stellt sich natürlich unweigerlich die Frage, was die bereits angedeuteten Vorteile von WebExtensions sind.
WebExtensions sind der neuste Standard für die Entwicklung von Erweiterungen, entsprechend fließen hier all die Erfahrungen ein, welche Mozilla im Laufe der letzten Jahre machen konnte. Während die Umstellung auf den neuen Standard sicherlich hart für die Entwickler-Community wird, bieten WebExtensions ein Fundament, welches eine nie dagewesene Zukunftssicherheit verspricht: durch die Entkoppelung von der Plattform sind WebExtensions von großen zukünftigen Änderungen nicht betroffen und benötigen keine weitere Anpasungen, sei es beispielsweise für die Nutzung weiterer Prozesse in der Multiprozess-Architektur, Sandboxing oder die Next-Generation-Engine Quantum.
Dies ist nicht nur ein Vorteil für Erweiterungs-Entwickler, nicht zuletzt dürfte dies auch der Entwicklung von Firefox selbst sehr zu Gute kommen, da Mozilla den Browser mit höherem Tempo weiterentwickeln kann, ohne die Kompatibilität von Erweiterungen zu gefährden.
Die Entwicklung von WebExtensions soll einfacher gegenüber der Entwicklung für ältere Erweiterungs-Architekturen sein – gerade für XUL-basierte Erweiterungen trifft diese Aussage zu. Auch die Entwicklung browserübergreifender Erweiterungen ist mit WebExtensions sehr viel einfacher, da Mozilla bei gleichen Funktionalitäten auf eine möglichst große API-Kompatibilität wert legt. So können Entwickler im Idealfall für Firefox, Chrome, Opera und Edge Erweiterungen entwickeln, ohne große Anpassungen vornehmen zu müssen. Einige dieser Schnittstellen sollen sogar standardisiert werden. Nichtsdestominder soll Firefox natürlich nicht auf das limitiert sein, was andere Browser unterstützen, Firefox wird auch in Zukunft einzigartige Anpassungsmöglichkeiten anbieten.
Sören Hentzschel ist Webentwickler aus Salzburg. Auf soeren-hentzschel.at informiert er umfassend über Neuigkeiten zu Mozilla. Außerdem ist er Betreiber von camp-firefox.de, der ersten Anlaufstelle im deutschsprachigen Raum für Firefox-Probleme aller Art. Weitere Projekte sind firefox.agenedia.com, firefoxosdevices.org sowie sozone.de.
Mhm ich hoffe das wir auch weiterhin Werbung effektiv filtern können und den Anti-Adblock Scripts paroli bieten.
Gibt es für WebExtensions eigentlich eine Möglichkeit Skripte zu filtern und zu modifizieren die in der Webseite stecken?
https://github.com/whatwg/html/issues/943 macht einem Wenig Hoffnung
@Newt:
Das ist selbstverständlich auch mit WebExtensions möglich.
Das kann ich dir nicht beantworten, ich habe mich auch noch nicht im Detail mit den bereits vorhandenen APIs beschäftigt. Vielleicht findest du in der Dokumentation etwas:
https://developer.mozilla.org/de/Add-ons/WebExtensions
WebExtensions sind eine feine Sache, habe damit sogar schon selbst eine kleine Erweiterung für Firefox und Edge geschrieben. Dass Add-Ons in Zukunft in fast jedem Browser ohne große Anpassungen laufen werden, ist ein wichtiger und richtiger Schritt.
Natürlich gibt es bei mir auch Zweifel, u.a. bei so großen Add-Ons wie DownThemAll!, die noch auf XUL setzen. Wie tux bereits schrieb, ist es bisher ja leider nicht möglich, den Downloadprozess zu verändern oder auch nur den Downloaddialog zu modifizieren… Ich hoffe, da kommt noch was derartiges.
Eine Frage habe ich aber noch… betrifft das auch Add-Ons, die mit dem JetPack SDK erstellt wurden? Also werden dann wirklich NUR WebExtensions und keine anderen in Zukunft mehr unterstützt? Wären das nicht ein sehr großer Teil der Add-Ons? Oder missverstehe ich da was?
Das kommt jetzt doch überraschend bald und "aggresiv".
Ob damit das große Extension-Sterben beginnt? Ich habe meine Extensions seit e10s schon abgespeckt, dennoch sind die Wenigsten bereits WebExtenions (eigentlich nur Enhanced Steam).
Von uBlock Origin gibt es seit kurzem eine WebExtensions-Version, der allerdings noch einige APIs in Firefox fehlen, um wie bisher zu funktionieren.
Bleibt die Frage was mit Tab Mix Plus, Greasemonkey, Stylish und Co. passiert 🙁
Hoffentlich gibt es auch für WebExtensions die Möglichkeit, das DevEdition Theme in den release-Versionen anwählbar zu machen. Das ist das einzige Feature, für das ich zur Zeit eine Erweiterung (devedition-theme-enabler) verwende.
Ich halte den Zeitplan für sehr ehrgeizig/ambitioniert, wobei ich mich freuen würde, wenn es klappt. Aber ich glaube, dass es extrem negative Reaktionen von Entwicklern geben wird, die Mozilla dazu zwingen könnten, die Deadline zu verschieben.
Browser-übergreifende Kompatibilität von add-ons wäre natürlich ein Traum, und die Versprechen von WebExtensions klingen echt gut. Für mich bleiben noch 2 Fragen:
1. Sind WebExtensions eigentlich auch schneller/performanter als andere Erweiterungen?
2. Kann man irgendwo nachschauen, ob ein Add-on eine WebExtension ist? Ich benutze zB uBlock Origin, wobei ich nicht weiß, ob das eine WebExtension ist oder wie ich das nach gucken kann :/
Da ich gestern danach gesucht habe:
Gibt es eine Liste von (populären) Addons und die Info, ob diese auf alter oder neuer Architektur basieren?
Kann sofort losgehen mit der Migration. Bin bereit. Jedenfalls sobald es APIs wie js-ctypes und child process gibt. Bisher konnte ich nicht eines meiner Addons als Webextension programmieren. Würde sagen läuft alles, wie damals schon vermutet, als die WEs angekündigt wurden.
Es ist ja nicht so, dass man erst von Mozilla dazu gezwungen wurde, die alten XUL Add-ons auf die SDK-Variante zu portieren. In diesem Zuge hätten viele sicherlich gerne direkt auf die neuen WebExtensions umgestellt. Doch leider war der Funktionsumfang letztes Jahr alles andere als gut und aktuell sieht es noch nicht viel besser aus. D.h. in wenigen Jahren dürfen bzw. durften die Entwickler mehrfach portieren. Das machen vielleicht einige Entwickler von kleinen Add-ons noch mit, aber gerade für komplexere Add-ons dürfte es viel Arbeit bedeuten und da machen sicherlich nicht mehr alle mit. Und die User wundern sich, warum dann Add-ons plötzlich nicht mehr funktionieren und wechseln letztendlich den Browser.
@Andreas:
Das betrifft auch SDK-basierte Erweiterungen. Ja, es sind viele Add-ons betroffen.
@blub:
Ich weiß jetzt nicht, ob ich das "nur" richtig verstehe (das klingt, als wäre es nur eine einzige Erweiterung), aber Stand August 2016 waren auf AMO bereits mehr als 700 WebExtensions hochgeladen.
@Daniel:
Beschwerden sind natürlich garantiert (bei Mozilla reicht es ja schon, wenn sie nur einen Pixel in der Oberfläche ändern und schon gehen einige auf die Barrikaden. Und das hier ist ein paar Nummern größer) und eine Verschiebung der Deadline sicherlich im Bereich des Möglichen. Allerdings sollte man sich darüber im Klaren sein, dass man die Deadline noch sehr verschieben kann, der Standpunkt derer, die damit unzufrieden ist, wird sich dadurch kaum ändern, also wäre eine Verschiebung vermutlich nicht mehr als eine Verzögerung. Wenn eine Verschiebung hingegen produktiv genutzt wird und dazu beiträgt, dass einige Erweiterungen mehr erhalten bleiben, dann gerne.
Ich denke nicht, dass sich das pauschal sagen lässt. Messungen diesbezüglich sind mit in jedem Fall nicht bekannt. Wobei zumindest bekannt ist, dass das Add-on SDK ziemliche Performance-Probleme hat(te), die man teilweise in Firefox 50 angegangen ist, insbesondere der Module-Loader.
Eine Liste ist mir nicht bekannt. Innerhalb der Erweiterung siehst du es an der Existenz einer Datei manifest.json.
uBlock Origin ist keine WebExtension, wobei der Entwickler bereits an einer WebExtension-Version arbeitet.
@Simon:
Ist mir nicht bekannt, zumal es verschiedene Typen gibt: XUL-basierte Erweiterungen, SDK-basierte Erweiterungen, Bootstrapped Erweiterungen, WebExtensions, Hybrid-Erweiterungen (SDK-basiert plus WebExtension oder Bootstrapped Erweiterung + WebExtension).
WebExtensions erkennst du daran, dass es eine Datei manifest.json gibt.
@Tobias:
Richtig, ist nicht so. XUL-basierte Erweiterungen waren bisher und sind nach wie vor ohne jede Einschränkung nutzbar. Und als die XUL-Deprecation erstmals vor mehr als einem Jahr angekündigt worden ist, wurde von Anfang an gesagt, dass WebExtensions die Zukunft sind. Niemand wurde zu einem Zwischenschritt auf das SDK gezwungen. Wobei die Migration von einem SDK-basierten Add-on zu einer WebExtension sicherlich einfacher ist als von einer XUL-basierten Erweiterung. Insofern kann das durchaus hilfreich gewesen sein.
Das kann man so keinesfalls stehen lassen, weil sich in der Zeit extrem viel getan hat. Das heißt nicht, dass nicht noch eine Menge Arbeit bevorsteht, aber "nicht viel besser" stimmt sicher nicht.
Dazu wurde niemand gezwungen.
Eher umgekehrt. Gerade bei den großen Erweiterungen ist die Wahrscheinlichkeit hoch, dass diese angepasst werden, denn diese Erweiterungen sind nicht umsonst groß geworden. Gerade bei den aktivsten Erweiterungen lässt sich eine vermehrte Kommunikation mit Mozilla nachvollziehen.
Warum sollen sie bitte den Browser wechseln? Wenn eine Firefox-Erweiterung nicht mehr funktioniert, funktioniert sie in Chrome oder sonst wo noch lange nicht.
Wie (über einen Tag, …) sind diese zu finden?
Ich habe diese Information aus dem offiziellen Add-on-Blog von Mozilla. Mozilla hat Möglichkeiten, solche Informationen zu erhalten, ohne jedes Add-on herunterladen zu müssen. Eine öffentliche Liste ist mir wie gesagt nicht bekannt. 😉
Da hier und in Foren von einigen immer wieder geschrieben wird, das alte Add-ons nicht mehr gepflegt / portiert und damit nutzbar sind / sein werden. Zur Software-Entwicklung gehört, dass eine Software, dazu gehört auch ein Add-on, regelmäßig gewartet und an Änderungen angepasst wird. Ein nicht mehr gepflegtes Add-on kann auch eine Sicherheitslücke darstellen oder eben zu Abstürzen führen. Bei uns in der Firma werden Apps bereits mit einem Datum versehen, bis zu dem sie verwendet werden können. Dann gibt es zwei Möglichkeiten, die App wird nicht mehr unterstützt, und wurde aus den App-Stores entfernt, oder es steht ein Update bereit.
Weil man davon ausgeht, dass man Firefox in erster Linie aufgrund dieser Erweiterung(en) benutzt.
Ich wiederhole: Wenn eine Firefox-Erweiterung nicht mehr funktioniert, funktioniert sie in Chrome oder sonst wo noch lange nicht. Das Argument ergibt keinen Sinn.
Übrigens nutzt knapp die Hälfte aller Firefox-Nutzer nicht ein einziges Add-on, das ist eine Tatsache und schwächt dieses Argument weiter.
Gerade DownThenAll ist einer der Gründe, überhaupt Firefox zu verwenden. Natürlich werde ich nicht wechseln, wenn es dieses Addon nicht mehr gibt.
Auf der anderen Seite frage ich mich, warum kein Browserhersteller es bislang für nötig gehalten hat einen rudimentären Downloadmanager einzubauen der wenigstens eine Warteschlange besitzt und der die Anzahl der gleichzeitigen Downloads beschränkt.
Es macht auch bei schnellen Internetleitungen wenig Sinn mehrere hundert MB oder GB große Downloads gleichzeitig zu starten.
Das ist ja überhaupt nicht gesagt, dass es das in einem Jahr nicht mehr gibt.
Weil das ganz sicher keine Funktionalität ist, für welche die Masse der Nutzer eine Verwendung hat.
Mit welcher Begründung?
Weil die Masse aus DAUs besteht, die es deswegen nicht nutzen weil sie es nicht kennen?
Es aber dennoch zu schätzen wüssten, wenn es das gäbe?
Es macht also wirklich Sinn, selbst mit einer 50 oder 100Mbit Leitung zehn oder zwanzig Downloads von mehreren GB gleichzeitig zu starten?
Und bevor jemand fragt. Es gibt durchaus legale Quellen und Möglichkeiten "so viel" herunterladen zu wollen.
Wie kommst du darauf, dass a) diejenigen, welche es nicht nutzen, DAUs wären (was übrigens keine sehr respektvolle Bezeichnung ist), und b) dass es zu schätzen wüsste, wer es kennen würde?
Einen Anwendungsfall hast du keinen einzigen genannt. Und selbst, wenn es einen gibt, dann ist das ganz sicher keine Notwendigkeit in den meisten aller Fällen. Das ist ein spezieller Wunsch und daher perfekt in einem Add-on platziert.
Wieso sollte es keinen Sinn ergeben? Oder anders formuliert: welcher reale Vorteil entsteht dadurch, die Downloads nacheinander zu starten? Und noch wichtiger: ist das ein Anwendungsfall, welcher sagen wir 90 Prozent aller Downloads betrifft? Wohl kaum.
Wenn wir schon dabei sind: Warum sind denn all diese Developer Tools fest in Firefox enthalten? Die braucht nun garantiert nur ein Bruchteil der User.
Ich kenne jedenfalls genau gar niemanden, der die je benutzt hat…
Mit einem "Bruchteil" liegst du garantiert falsch. Nicht grundlos sind Entwickler-Werkzeuge Bestandteil von ausnahmslos (!) jedem (!) Browser mit Markt-Relevanz. Dass du wirklich niemanden kennst, der diese nutzt, zeigt nur, dass die Erfahrung eines Einzelnen nichts über die Relevanz für den Markt aussagt. 😉
Selbst Schüler kommen im Rahmen des Informatikunterrichts an fast jeder Schule mit HTML und CSS in Berührung und benötigen dafür Werkzeuge. Ganz abgesehen davon sind Webseiten der eine große Job von Browsern und Webseiten kann man nicht nur konsumieren, man muss sie ja auch entwickeln. Webseiten entwickeln kann nicht nur ein Bruchteil, das können sehr viele Millionen Menschen. Die einen besser, die einen weniger, aber das tut nichts zur Sache. Gerade Mozilla steht ausdrücklich dafür, das Web nicht nur zu konsumieren.
Entwickler-Werkzeuge besitzen für Browser eine sehr große Bedeutung und de facto ist es sogar eine Tatsache, dass es nicht gerade wenige Nutzer gibt, welche die Wahl ihres Browsers primär oder zumindest auch von den vorhandenen Entwickler-Werkzeugen abhängig machen. Schlechte Entwickler-Werkzeuge sind kein seltener Grund, um einen Browser zu wechseln.
Die Entwickler von Webseiten, ob nun professionell oder hobby-mäßig, sind übrigens auch daher eine besondere Zielgruppe, weil diese Menschen erfahrungsgemäß eher den Browser "bei den Großeltern" installieren und anderen Menschen empfehlen oder davon abraten. Mit anderen Worten: Mit jedem Webentwickler steigt oder sinkt der Marktanteil mit einer höheren Wahrscheinlichkeit um noch weitere Menschen als bei anderen Zielgruppen. Das ist eine Beobachtung, die man immer wieder in der realen Welt machen kann.
Gibt es dazu verläßliche Zahlen? Kaum. Die Leute, von denen ich spreche, sind sogar ziemlich Computer affin.
Der größte Teil der PC Benutzer ist das überhaupt nicht, und die haben wohl nicht mal die leiseste Ahnung, wozu diese Tools überhaupt nütze sind.
Übrigens, bezüglich WebExtensions: http://forums.mozillazine.org/viewtopic.php?p=14721955#p14721955
Zitat Aris:
Natürlich gibt es dazu keine Zahlen, sowas ist schließlich nicht messbar. Aber das ist ja eh naheliegend.
Der größte Teil heißt "> 50 Prozent"? Abgesehen davon, dass du dafür genauso wenig Zahlen besitzt, wären bereits 20 Prozent mehr als ausreichend Rechtfertigung, was immerhin rund 100 Millionen Nutzern entsprechen würde. Glaubst du wirklich, dass wirklich weniger als jeder Fünfte jemals von HTML und CSS gehört hat? Im Prinzip sind bereits fünf Prozent Rechtfertigung genug, wenn du ernsthaft damit argumentieren möchtest. Oder was glaubst du, wie oft diverse Einstellungen von Firefox überhaupt von Nutzern geändert werden? Da sprechen wir in der Regel von unter fünf Prozent. Wäre das ein Grund, etwas nicht anzubieten, dann würde Firefox wohl ohne jede Einstellungsmöglichkeiten für Nutzer ausgeliefert werden. Du siehst, so funktioniert das nicht. Es muss nicht jeder Nutzer eine Funktion nutzen, so etwas gibt es nämlich nicht. Ja, es gibt sogar Nutzer, die ohne Adressleiste oder ohne Tabs einen Browser nutzen, kein Scherz. Es gibt nahezu unendlich viele Anforderungen an einen Browser und ein Browser muss möglichst viele davon zufriedenstellen und das geht nur, indem möglichst viele Funktionen angeboten werden. Entwickler-Werkzeuge sprechen aber vollkommen ohne Zweifel eine überdurchschnittlich große und wie erwähnt auch eine überdurchschnittlich wichtige Zielgruppe an.
Ich kenne diese Aussage und sie ist Schwachsinn. Denn das, was der gute Aris vermisst, bieten andere Browser gar nicht erst an, diese Aussage ergibt also keinen Sinn. Zusätzlich ergibt diese Aussage nochmal keinen Sinn vor dem Hintergrund, den ich bereits im Artikel beschrieb: WebExtensions heute entsprechen nicht WebExtenions in einem Jahr.
Ehrlich gesagt, ich halte von dieser gnadenlosen Umstellung, die die Existenz bedeutender Add-Ons – Stand: heute – gefährdet, rein gar nichts. Martin Brinkmann weißt auf gHacks z. B. darauf hin, dass es dem Classic Theme Restorer an den Kragen gehen könnte (http://www.ghacks.net/2016/11/26/classic-theme-restorer-may-be-dead-by-the-end-of-2017/). Für mich ist das eines der Add-Ons schlecht hin neben einer Reihe von rund zehn weiteren, die ich schmerzlichst vermissen würde. Der Firefox ist der Browser mit der größten Multi-Kultur in Sachen Anpassung, ein Pfund, mit dem man seitens Mozilla wuchern müsste. Stattdessen verschlankt man sich immer weiter in Richtung Mono-Kultur eines Internetriesen in Aussehen und Standards. Mir erschließt sich schlicht die Notwendigkeit nicht.
Ich habe seit Firefox 1.0 so manche Veränderung erlebt und mitgemacht, aber wenn nun Ende 2017 so gravierend in das Nutzungsmodell des Firefox eingegriffen wird (die Einführung von Australis, von mir leidenschaftlich gehasst, war ein Witz dagegen), werde ich ganz sicher zum Slimjet wechseln, der jetzt schon mein Zweitbrowser ist. Dort kann ich zwar nicht viel anpassen, aber er ist gegenwärtig der Chromiumbrowser, mit dem ich am besten von den Grundeinstellungen her arbeiten kann.
Ich halte von ghacks und besonders von Martin sehr viel, aber was diesen Artikel betrifft, stimme ich dem ersten Kommentar unter dem Artikel zu: diese Headline ist Clickbaiting und nicht das Niveau, welches ghacks üblicherweise hat.
Mozilla hat die exklusive WebExtension-Unterstützung für Firefox 57 angekündigt. Das ist eine beschlossene Tatsache und wurde dort genau wie hier in einem Artikel behandelt. Dieser neue Artikel schreibt nun nicht eine einzige Sache, die neu ist. Es wird der bereits bekannte Umstand wiederholt, bloß emotional verschärft, indem eine Annahme für einen Zeitpunkt getroffen wird, der noch über ein Jahr entfernt liegt, und was dann sein könnte, aber niemand weiß.
Ganz ehrlich, was soll dieser Artikel, außer unnötig Emotionen anheizen? Ich hab keine Erklärung für den Sinn dieses Artikels.
Ganz sicher wird in Zukunft nicht alles möglich sein, was in der XUL-Welt möglich ist. Das war bereits vor mehr als einem Jahr ein bekannter Umstand. Aber es ist vollkommen sinnlos, den heutigen Stand von WebExtensions als Bewertungsgrundlage für die Situation in mehr als einem Jahr herzunehmen.
Was du mit dem Punkt Verschlankung in Richtung Mono-Kultur eines Internetriesen in Aussehen und Standards meinst, ist mir absolut schleierhaft. In vielen Standards ist Mozilla führend, sei es die Implementierung neuer ECMAScript-Features, ganz aktuell CSS Grids oder Innovationen wie asm.js. Das Aussehen von Firefox unterscheidet sich sehr deutlich von dem von Chrome (falls du das meinst). Und von Verschlankung kann auch keine Rede sein. Das Fundament wird modernisiert und das ist auch dringend notwendig. Teilweise führt auch technisch kein Weg daran vorbei. Aber auch in der WebExtensions-Welt werden immer mehr APIs implementiert, das ist keine Verschlankung aus Prinzip. XUL muss aus Firefox verschwinden, das ist seit nun mehreren Jahren bekannt. Jedem, der sich mit Firefox befasste, war klar, dass dieser Tag kommen wird. Das hat auch nichts mit anderen Browsern zu tun, sondern nur mit Mozilla selbst, die XUL damals erfunden hatten.
Sich über Australis aufzuregen kann auch als Witz gesehen werden. Es kann nunmal nur ein Standard-Design geben und nicht jedem gefällt das gleiche Design. Pech für diejenigen, denen das nicht gefällt, sonst gar nichts.
Ich habe nicht behauptet, dass es ein sonderlich gutes Argument ist, aber so liest man das eben oft 😉 Firefox wäre ja technisch komplett abgehängt und der einzige große Grund ihn noch zu benutzen, wären die Addons.
CTR dient ja hauptsächlich dem Zweck, Australis vergessen zu machen. Wie viele Jahre ist das jetzt das Standard-Theme für Firefox? Ich verstehe nicht, wieso man sich nicht anpassen kann, gerade bei so extrem schnell entwickelnder Software wie Browsern ändert sich eben auch mal was Großes, und gerade mit der Verschiebung von Software Richtung Clouddiensten, wird die Anpassbarkeit weiter leiden.
Bei solchen Aussagen muss ich immer an die XP-Jünger denken, die heute noch mit ihrem unsicheren Betriebssystem kämpfen, obwohl Windows in allen Belangen so viele Fortschritte gemacht hat.
Was nebenbei meiner Meinung nach auch kaum Auswirkungen auf die Beliebtheit von Firefox im Massenmarkt bedeutet. Oder lassen sich Mobile-Apps anpassen? Nein, in der Regel kein bisschen. Da wächst eine ganze Generation heran, die sich nie mit Modding, Kommandozeile und sonstigen "Geekmanövern" befasst hat. Warum sollte ein Firefox ohne CTR da failen?
Was mich schon eher verwundert:
Warum basieren selbst aktuelle Mozilla-Experimente wie Tab Center (was mir übrigens sehr gut gefällt), noch nicht auf WebExtensions?
Das wäre doch eine super Möglichkeit, zu zeigen was damit möglich ist und auch um diesen Schritt zu werben. So wirkt es eher, als wäre Mozilla selbst noch nicht ganz klar, was man mit dem Schritt zur WebExtensions-Exklusivität alles verlieren wird.
Tja, es befassen sich eben zu wenige mit den Tatsachen und die Medien unterstützen das Gerede ja auch sehr… 😉
Der ursprüngliche Gedanke mag das gewesen sein, ich würde von dieser Beschreibung mittlerweile aber sogar weg gehen. CTR bietet so viele Funktionen an, welche dem Zweck dienen, die Oberfläche zu ändern, mit Australis hat das meiste überhaupt nichts mehr zu tun. 😉
Mehr als 2 1/2 Jahre. 😉
Tja, es gibt ein paar Rätsel auf dieser Welt. 😀
Aus dem naheliegendsten Grund: WebExtensions unterstützen einige Dinge nicht, welche im Rahmen von Test Pilot umgesetzt sind. Mozilla ist sich sehr gut über alles im Klaren, aber bei Test Pilot geht es ausdrücklich darum, Funktionen zu testen. APIs für Erweiterungen zu entwickeln ist eine komplett andere Geschichte. Und Mozilla geht bei den WebExtensions mit APIs sehr behutsam um, denn WebExtension-APIs sind mit einem Versprechen verknüpft: Stabilität. Diese APIs sollen über viele Jahre Bestand haben und nicht permanent von Entwicklern der Erweiterungen Anpassungen erfordern. WebExtensions werden schließlich nicht nur eingeführt, um Dinge anders zu machen, Mozilla will es besser machen als bisher. Mozilla implementiert nur die APIs, von denen sie sich sicher sind, dass Mozilla diese API so in Firefox sehen möchte. Müssten erst die APIs existieren, würde das Mozillas Test Pilot-Programm enorm einschränken.
Australis – in meinem Fall: es geht nicht darum, dass ich mich nicht an Australis kann. Wäre es so, hätte ich ja große Probleme, Chrome oder Slimjet zu bedienen. Dem ist selbstverständlich nicht so. Und Australis mit XP zu vergleichen, ist albern, denn XP ist de facto ein Sicherheitsrisiko, wenn auch in geringerem Umfang mit dem POSReady/WEPOS-Hack.
Das ursprüngliche Design ist für mich einfach angenehmer zu bedienen und ich denke, wenn Ihr nachfolgendes Bild seht, dürftet Ihr die Übersichtlichkeit zu schätzen wissen:
http://fs5.directupload.net/images/161127/jr4kndtg.jpg
Zur Cloud: kein Interesse. Es mag zwar momentan hipp sein, wird sich langfristig aber zerlegen. Zwei drei große Datenskandale hintereinander (z. B. DDoS-Angriffe aus dem IoT oder gar Datenhack-Attacken) mit ggf. millionenfachen Datenverlusten und das Thema ist durch. Ist nicht eine Frage des Ob, sondern des Wann.
Für die Einführung von Australis bestand damals schlicht keine Notwendigkeit – maßgeblich war die IMO naive Illusion, als Chrome-Look-Alike mithalten zu können. Hat Mozilla de facto nichts genutzt, der Chrome-Browser setzte seinen Siegeszug in der Userschaft unbeirrt fort. Zurück blieb ein Firefox-Userkern, der fortan begann, gegen Mozilla gerichtete Add-Ons zu nutzen.
Ehrlich gesagt, das einzige, was ich denke, wenn ich das sehe, ist: furchtbar. Ich finde das richtig schlimm. 😉
Chrome-Look-Alike? Die Unterschiede zu Chrome sind enorm. Wer sowas behauptet, kann entweder Firefox oder Chrome nicht sehr gut kennen oder einen sehr inakkuraten Blick haben, was Design betrifft. 😉
Schlicht keine Notwendigkeit ist auch einfach mal komplett falsch. Eine Notwendigkeit für gute Optik besteht in einem Softwareprodukt für den Massenmarkt immer. Und dass das alte Design altbacken und alles andere als modern war, ist nun einmal so, darüber braucht man nicht zu reden. Die Geschmacksfrage muss jeder für sich selbst beantworten, das ist subjektiv, für die Masse gelten objektive Maßstäbe. Letztlich ist es ein Standard-Design und das Standard-Design kann nunmal nicht jedem gefallen. Ich fand's vorher hässlich und nun sehr schön. Wie ich schon sagte: Pech, wem's nicht gefällt. Sonst gar nichts.
Die Aussage "Zurück blieb ein Firefox-Userkern, der fortan begann, gegen Mozilla gerichtete Add-Ons zu nutzen" muss ich hoffentlich nicht verstehen. Ich hoffe, du meinst damit nicht die Existenz des "Classic Theme Restorer". Das Add-on hat mit Australis nicht mehr viel zu tun, es ist eine Lösung, um unzählige Aspekte der Oberfläche zu ändern, das wenigste davon hat mit Australis zu tun. Und so beeindruckend 430.000 Nutzer auch sind, das sind halt letztlich auch nur 0,09% von 480 Millionen Firefox-Nutzern. Und Statistiken zur Nutzung von Firefox belegten damals übrigens, dass Australis ein Erfolg für Mozilla war. Denn die durchschnittliche Nutzungszeit von Firefox hatte sich mit Firefox 29 (da wurde Australis eingeführt) erhöht.
@Sören
Naja, das stimmt schon so: Vielleicht nicht rein auf XUL bezogen, aber auf die alte Add-on-Architektur. So hat man im August 2015 verkündet:
D.h. es war Handlungsbedarf! Und zu dem Zeitpunkt war die WebExtension-API mangels Features noch keine Alternative. Und man hat auch mit keinem Wort erwähnt, die Unterstützung des Add-on SDKs in knapp 2 Jahren mit Firefox 57 zu beenden.
Und wenn ich mich nicht irre, fehlen immer noch wichtige APIs wie z.B. "Proxy Filter", was von ca. 15 Millionen Usern genutzt wird.: https://mail.mozilla.org/pipermail/dev-addons/2016-July/001649.html
Es mag dann auch so sein, dass wenn SDK Add-ons nicht mehr funktionieren, die User auch bei Chrome keine Alternative zum jeweiligen Add-on haben. Aber wie User nun mal so sind, wenn etwas nicht funktioniert, wird gewechselt, egal ob der neue Browser zwingend besser ist.
Den Satz verstehe ich nicht. Es gibt nicht "die alte Add-on-Architektur". Es gibt verschiedene Add-on-Architekturen, u.a. WebExtensions, SDK-basierte Erweiterungen, XUL-basierte Erweiterungen, Bootstrapped Erweiterungen. "Alt" sind alle außer WebExtensions.
Da geht es doch um etwas vollkommen anderes. Da geht es ausdrücklich um CPOWs und Kompatibilitäts-Shims für e10s. Das hat absolut gar nichts mit der Add-on-Architektur zu tun.
Für XUL-Erweiterungen wurde ein vorläufiger Zeitraum von 12-18 Monaten angegeben. Nun dauert es länger als das. Das kann für Entwickler von Erweiterungen nur ein Vorteil, auf gar keinen Fall ein Nachteil sein. Es wurde damals aber schon ausdrücklich geschrieben, dass dies keine verbindliche Angabe, sondern nur eine Voraussicht ist.
Du hast es übrigens selbst mit zitiert:
Und es gab weitere Kommunikation seit August 2015.
Falsch. Entwickler sollten selbstverständlich immer auf dem Laufenden bleiben und sich natürlich auf Dinge einstellen. Insofern gut, wenn sich Entwickler frühzeitig eingestellt haben. Aber es gab nie den Handlungsbedarf, eine Erweiterung umzustellen, bevor es tatsächlich notwendig war. Und wann etwas notwendig ist, wird von Mozilla immer kommuniziert.
Ich habe auch schon eine Work-In-Progress WebExtension von New Tab Override. Die entwickle ich in einem separaten Branch und werde die Haupt-Erweiterung erst dann umstellen, wenn die Zeit gekommen ist. Nur, weil Arbeiten daran existieren, muss ich nicht etwas ausliefern, obwohl das alte noch wunderbar funktioniert. Ich kann warten, neue APIs beobachten und ggfs. verwenden, sobald sie verfügbar sind. Und wenn was dazu kommt, was ich noch vermisse, hab ich bereits angefangen und muss nicht mehr alles neu machen. So sollte das funktionieren, sich frühzeitig auf etwas einzustellen. Diese Strategie hat vor allem den Vorteil, dass man Mozilla mitteilen kann, welche APIs man noch benötigt. Ich habe als Konsequenz meiner WebExtension-Arbeit hinterher auch mehrere Bugzilla-Tickets mit Wünschen eröffnet.
WebExtensions wurden als erste offizielle stabile Version ja auch erst mit Firefox 48 eingeführt. Das ist also klar, dass das keine Alternative damals gewesen sein kann, damals gab es noch nicht einmal eine stabile Veröffentlichung. Aber mit jedem neuen Firefox-Release kommen auch einige WebExtension-Neuerungen und das wird 2017 nicht anders laufen, d.h. es kommt noch einiges dazu, was jetzt noch nicht da ist.
Ja, ich hätte im August 2015 auch nicht damit gerechnet, dass die Deprecation von XUL und SDK gleichzeitig geschehen wird, das war damals wahrscheinlich auch noch gar nicht klar. Dass das grundsätzlich kommen wird, ist meines Erachtens aber keinesfalls überraschend. Ich meine, selbst im Firefox-Forum, wo sich Nutzer gar nicht mit der Entwicklung von Erweiterungen befassen, war vielen schnell klar, dass Mozilla irgendwann komplett auf WebExtensions setzen wird. Ich sag's ehrlich, manchem Nutzer, der wirklich gar nichts von der Erweiterungs-Entwicklung versteht, kam sogar schon vor mir zu diesem Schluss. Aber auch jetzt ist das noch ein Jahr Zeit – wenn nicht sogar länger. Wer sich mit Mozilla befasst, der weiß, dass wenn Mozilla solch langfristige Ankündigungen macht, es häufig noch viel später wird. Sei es damals Australis, sei es Electrolysis, sei es die Signierung von Erweiterungen, alles hat länger gedauert als ursprünglich angepeilt. Aber das ist so herum auch viel besser als umgekehrt. Lieber zu früh auf etwas eingestellt sein als zu spät.
An dieser API wird momentan gearbeitet. Dass die in einem Jahr spätestens bereitsteht, ist also sehr wahrscheinlich.
Das ergibt absolut keinen Sinn. Es geht dabei doch gar nicht darum, ob ein anderer Browser besser ist oder nicht. Aber wenn ich einen Browser wechseln will, weil er eine Sache X nicht unterstützt, dann kann ich nicht zu einem Browser wechseln, der eben jene Sache X auch nicht unterstützt. Dahinter steckt keine Logik.
Ja, das hat nichts mit XUL zu tun, wurde aber quasi im gleichen Zeitraum verkündet und hat insofern natürlich auch etwas damit zu tun, dass man seine Add-ons hat anpassen müssen.
Nicht jeder Entwickler hat immer gleich Zeit, und ich für meinen Teil hasse es, wenn ich weiß, dass in absehbarer Zeit etwas nicht mehr funktionieren wird und es noch keine vernünftige Lösung gibt, das jetzt umzustellen, wenn ich Zeit habe.
Kann man so machen, dem will ich auch gar nicht widersprechen. Ich mag es allerdings nicht, Dinge zwei Mal zu machen, die im Prinzip dasselbe Bewirken. Nichts anderes ist es, ein bereits funktionierendes Add-on zu portieren. Und wenn man dann sieht, dass Firefox mit jeder Version eh schon "größer" wird, dann fragt man sich, warum man nicht einfach die alten SDK-Teile abwärtskompatibel lässt?
Ein unzufriedener User folgt leider keiner Logik, er handelt emotional. Wenn sich Leute aufregen (über was auch immer, kann auch ein Handy oder Auto sein) und unzufrieden sind, suchen sie alternative Anbieter.
Und dennoch hat es nichts damit zu tun, ob nun XUL-basiert, SDK-basiert, Bootstrapped Erweiterung, WebExtension oder ein Hybrid aus Bootstrapped Erweiterung plus WebExtension oder SDK-basiert plus WebExtension. Genau das war ja die Aussage, dass man die Architektur bereits hätte wechseln müssen, das stimmt einfach nicht. Wurden Kompatibilitäts-Shims oder CPOWs genutzt, hätte diese Nutzung auch ohne Wechsel der Erweiterungs-Architektur eliminiert werden können. Das ist davon nicht abhängig.
Genau deswegen kann man es so machen, wie ich mit New Tab Override. Ich hab einfach mal in einem separaten Branch begonnen, ohne den Plan, dass dieser Branch zwingend das nächste Update wird. In dem Branch wird immer dann gearbeitet, wenn Zeit ist. Das ist genau die Arbeitsweise, die einem am Wenigsten Druck macht. Man muss Änderungen nicht an Nutzer ausliefern, bevor es nicht notwendig ist.
Das ist schon was Anderes, weil ich kein funktionierendes Add-on portiere, nur um es auf eine andere Architektur gebracht zu haben. Es ist eine Notwendigkeit, dass die Arbeit bis (nach aktueller Planung) spätestens November 2017 abgeschlossen ist, weil das Add-on sonst nicht mehr funktionieren wird. Entsprechend ist man gut damit beraten, sich frühzeitig mit der notwendigen "Forschung" zu befassen. Wenn man nicht jetzt schon versucht, seine Erweiterung zu portieren, wann will man Mozilla dann die APIs vorschlagen, die einem noch fehlen? Ich zumindest tu mich da sehr schwer, ohne vorher Prototyping betrieben zu haben, was bereits möglich ist und was nicht. Nur durch Dokumentationen lesen, geht zwar, aber so denke ich nicht an jede Kleinigkeit, die später wichtig sein könnte. Das ist zumindest meine Erfahrung.
Weil das nicht funktioniert. Nehmen wir zum Beispiel die Berechtigungen für Erweiterungen. SDK-basierte Erweiterungen kennen sowas nicht. Was bringt das ganze Berechtigungs-System von WebExtensions (dass der Nutzer etwas von den Berechtigungen sieht, wird erst noch eingeführt, das ist noch nicht da!), wenn man die Berechtigungen durch eine andere Erweiterungs-Architektur umgehen kann? Du siehst außerdem an meinem ersten Absatz bereits, wie viele Architekturen es gibt. Das bedeutet auch eine enorme Komplexität für das Produkt. Es ist schon ein Vorteil, aus verschiedenen Perspektiven, wenn es nur eine Architektur gibt. Natürlich ist es kein Vorteil, wenn damit dann Dinge nicht gehen, die man braucht, das ist ein klarer Nachteil. Aber ich meine vom Prinzip her, die Motivation dafür, ein einziges gutes Erweiterungs-System zu haben, die find ich naheliegend.
Das kann man aber nicht als Argument verwenden. Sonst könnte man auch direkt so anfangen: "Oh, ein Staubkorn. Ich wechsle zu Chrome". Argumente müssen schon irgendwo nachvollziehbar sein. 😉
Klar hätte ich die bisherigen Anpassungen, die für Electrolysis notwendig waren, auch ohne ein Wechsel zum SDK machen können. Ich für meinen Teil dachte aber, es ist "schlau" gleich auf die zu diesem Zeitpunkt "modernste" und stabilste Architektur zu wechseln. Klar jetzt bin ich schlauer, hätte mir den Schritt dann auch sparen können.
Naja, eigentlich sollte ein neues System im Ansatz mal das Abdecken, was das alte System konnte. Da braucht ja nicht jeder seine bisher genutzten APIs vorschlagen. Da sollte doch vieles schon klar sein, wenn man sich die Top 10 Add-ons ansieht.
Ja, da bin ich bei dir. Mir ist es auch lieber ein System zu haben, als viele verschiedene. Das SDK ist ja auch noch nicht so alt, warum hat man das dann überhaupt eingeführt und nicht gleich WebExtensions?
Das ist natürlich ärgerlich. Aber zumindest dürfte der Schritt vom SDK zu einer WebExtension dann kleiner sein als direkt von einer XUL-basierten Erweiterung zu einer WebExtension. Vielleicht kannst du auf diese Weise noch was Positives darin sehen. Und in der Zwischenzeit hast du ja auch noch Vorteile gewonnen, wie dass kein Neustart des Browsers mehr zur Installation notwendig ist. 😉
Das ist nicht möglich und ganz ausdrücklich auch nicht gewollt.
Das fängt ja schon damit an, dass die Architektur für XUL-Erweiterungen überhaupt keine echten APIs besitzt. Der Entwickler von Erweiterungen greift auf Firefox-Interna zu, nutzt Overlays, um die Oberfläche zu überschreiben und so. Das alles mit APIs abzubilden, das würde seine Zeit dauern.
Dann kommt aber dazu, was ich gerade andeutete: es ist auch gar nicht gewollt. Mit WebExtensions sind gewisse Garantien verknüpft. Wenn Mozilla einen Teil von Firefox ändert, soll die Erweiterung nicht plötzlich defekt sein und Anpassungen erfordern. Erweiterungen sollen nicht die Entwicklung von Firefox selbst behindern. Und Erweiterungen sollen nicht mehr alles machen dürfen, wie wichtige Firefox-Einstellungen ändern. Das sind alles Dinge, die in früheren Erweiterungs-Modellen Gang und Gäbe waren, mit WebExtensions will man das nicht.
Was die Top 10 betrifft, du kannst davon ausgehen, dass sich Mozilla diese ganz genau ansieht und dass das einen gewichtigen Faktor darstellt, wenn es um die Priorisierung von WebExtension-APIs geht. Natürlich ist es ein Ziel von Mozilla, dass gerade die meistgenutzten Erweiterungen auch mit WebExtensions umsetzbar sind – sofern es mit Mozillas Zielen vereinbar ist. Ich sag mal, eine Menge, was jetzt noch mit dem Classic Theme Restorer geht, wird garantiert nicht möglich sein.
Das ist jetzt keine zitierfähige Aussage, aber was ich mal gelesen habe, war ungefähr so, dass WebExtensions das sind, was das Add-on SDK bereits hätte werden sollen. Ich habe das so mitbekommen, dass Mozilla mit dem Add-on SDK ein paar grundlegende Dinge schlicht falsch gemacht hat.
Aber so jung ist das SDK auch nicht mehr, sind bald sieben Jahre, seit es in einer finalen Version von Firefox eingeführt worden ist. Natürlich wünscht man sich nicht, eine Erweiterungs-Architektur "schon" nach sieben Jahren komplett auszutauschen, aber es sind jetzt auch nicht erst drei Jahre oder so.
Zumindest bin ich mir mal sicher, dass Mozilla mit dem SDK einiges gelernt hat, was für die Entwicklung von WebExtensions vorteilhaft war. Auch bei Mozilla arbeiten ja nur Menschen, welche durch Zeit Erfahrungen sammeln. 😉
Eine aktuellere WebExtension-Statistik: Im November waren 65 Prozent aller Neueinreichungen WebExtensions, sind damit also schon die am meisten verbreitete Add-on-Art für neue Erweiterungen. Insgesamt gibt es auf AMO, Stand Mitte Dezember, mehr als 1.400 gelistete WebExtensions und deren Installationen machen zwölf Prozent aller Installationen aus.
Mein Addon speichert Daten in einer Datei bzw. tauscht Daten mit einem anderen Programm über Dateien aus. Das ist momentan mit WebExtensions nicht möglich.
Im Augenblick steht mir eigentlich nur XMLHttpRequest zur Verfügung, um Daten mit anderen Programmen auszutauschen. Native messaging scheint mir zu kompliziert zu sein. Liege ich damit richtig oder gibt es andere Möglichkeiten des Datenaustausches? Wird es in Zukunft möglich sein Daten in Dateien zu schreiben, Dateien zu lesen und zu löschen?
Viele Grüße
Agnieszka
Ich muß gestehen, daß ich auf Grund der diversen anstehenden Änderungen ein bisschen den Überblick verloren habe ;-). Werden XUL-Add-ons bereits im Rahmen der Aktivierung von e10s oder erst von Webextensions (Firefox 57 oder später) nicht mehr unterstützt?
@Agnieszka:
Ist Native Messaging in deinen Augen zu kompliziert, würde aber grundsätzlich funktionieren, oder funktioniert es damit nicht? Wichtiger Unterschied, darum frage ich. 😉 Ich kenne dein Add-on und seine Arbeitsweise nicht, daher kann ich das von außen nicht beurteilen.
Ich kann dir auch gar nicht wirklich weiterhelfen, wenn es darum geht, was momentan möglich ist und was nicht, denn intensiv befasst habe ich mich bislang nur mit den Dingen, die ich für New Tab Override benötige. Momentan ist es ja so, dass mit jedem Major-Release alle sechs bis acht Wochen auch WebExtension-Erweiterungen dazukommen, d.h. es ist mit jedem Firefox-Release mehr möglich. Aber ich befasse mich nicht aktiv in dem Maße damit, dass ich mir das merke, in jedem Fall werden diese Dinge immer im Add-on-Blog (http://blog.mozilla.com/addons/) dokumentiert.
Was in Zukunft möglich sein wird, ist aus besagtem Grund noch weniger für mich zu beantworten, denn wie gesagt kommen ja immer mehr Dinge dazu. Und ich kenne die Pläne für zukünftige APIs nicht.
@Mikel:
Die Multiprozessarchitektur e10s unterstützt grundsätzlich XUL-Add-ons, e10s ist ja auch schon für einige Nutzer aktiviert, inklusive für Nutzer von XUL-Add-ons, sofern vom jeweiligen Entwickler als e10s-kompatibel markiert. Das grundsätzliche Ende von XUL-Add-ons kommt erst mit Firefox 57 (sofern der angekündigte Plan eingehalten wird), keinesfalls früher. Es kann natürlich für einzelne XUL-Add-ons sein, dass diese nicht e10s-kompatibel sind, es gibt umgekehrt auch keine automatische Kompatibilitäts-Garantie.
@Agnieszka
Wenn dieser Bug bearbeitet wurde, sollte dies möglich sein: Bugzilla
Betreffend Native Messaging habe ich mir das Beispiel unter WebExtenssions>Native messaging angeschaut. Es sieht für mich relativ kompliziert aus. Auf Windows muss man u.a. manuell Einträge in der Registry setzen. Die WebExtension im Beispiel kommuniziert mit einem Phyton Skript. Ich verwende Node.js und habe somit kein Beispiel was ich schnell testen kann. Da die Verwendung von XMLHttpRequest in WebExtensions einfach ist und in den meisten Sprachen ein HTTP-Server mit relativ geringen Aufwand erzeugt werden kann, werde ich diese Form der Kommunikation verwenden und keinen Aufwand in Native Messaging investieren. Ich hoffe das Dateizugriff später implementiert wird.