Mozilla kündigt große Änderungen für Entwickler von Firefox Add-ons an
Mozilla hat heute eine Reihe von Ankündigungen gemacht, welche die Zukunft der Entwicklung von Add-ons für Firefox betreffen. Dabei geht es neben der Signierung von Add-ons und der kommenden Multiprozessarchitektur (Electrolysis, kurz: e10s) auch um die Einführung der sogenannten WebExtensions, welche größtenteils API-kompatibel mit Chrome, Opera und in der Zukunft ggfs. auch Edge ist, sowie um die Deprecation von XUL, XBL und XPCOM.
Auf die Entwickler von Add-ons für Firefox kommt eine Reihe von wichtigen Änderungen zu, die Mozilla frühzeitig kommuniziert, so dass Entwickler rechtzeitig über Mozillas Pläne informiert sind. Diese Änderungen seien notwendig, um Technologien wie die Multiprozessarchitektur Electrolysis (auch bekannt als e10s) oder Mozillas kommende Browserengine Servo zu unterstützen, die Nutzer besser vor Spyware und Aware zu schützen und außerdem die Zeit zu reduzieren, die es für die Reviews von Add-ons benötigt.
Neue Schnittstelle für browserübergreifend kompatible Add-ons
Die Entwicklung von Add-ons sollte nach Ansicht von Mozilla vergleichbar mit der Entwicklung von Webseiten sein: der selbe Code soll in verschiedenen Browsern funktionieren. Mit den sogenannten WebExtensions führt Mozilla eine neue Schnittstelle für Add-ons ein, welche größtenteils kompatibel mit Chrome und Opera ist – möglicherweise in der Zukunft sogar mit Microsoft Edge, wie Mozilla andeutet. Mozilla hat bereits Diskussionen mit anderen Browserherstellern gestartet, um zumindest einen Teil der Schnittstelle zu standardisieren und somit die browserübergreifende Kompatibilität auch langfristig zu gewährleisten. Dies bedeutet für Entwickler, die Add-ons für verschiedene Browser entwickeln, dass nur minimale Anpassungen notwendig sind und nicht für jeden Browser eine grundlegend unterschiedliche Erweiterung programmiert werden muss. Ein weiterer Vorteil der WebExtensions ist, dass diese die Multiprozessarchitektur der Browser direkt unterstützen. Eine erste Unterstützung für WebExtensions wird ab Firefox 42 verfügbar sein.
Multiprozessarchitektur („Electrolysis“ / „e10s“)
Die geplante Multiprozessarchitektur für Firefox macht große Fortschritte und wird bekanntermaßen große Auswirkungen auf die Kompatibilität von Add-ons haben, insbesondere von Add-ons, welche mit dem Inhalt von Webseiten interagieren.
Die neuen WebExtensions sind wie bereits erwähnt vollständig kompatibel mit e10s. Add-ons, die auf dem Add-on SDK basieren, auch bekannt als Jetpack, sind kompatibel, solange sie nicht require(‘chrome’) oder manche Low-Level-APIs nutzen, die Objekte im Content-Prozess berühren. Dann gibt es noch sogenannte Kompatibilitäts-Shims in Firefox, die dafür sorgen, dass Add-ons oder Teile von Add-ons auch in e10s funktionieren, obwohl sie noch nicht für e10s angepasst worden sind – dies allerdings zum Preis einer spürbar schlechteren Performance.
Einen verbindlichen Zeitplan für die Auslieferung von e10s in einer finalen Version von Firefox gibt es noch nicht. Fest steht, dass e10s in der Nightly Version sowie Developer Edition bereits standardmäßg aktiviert ist. Am 22. September wird Firefox 42 die Betaphase erreichen und e10s den Nutzern per Opt-In zur Aktivierung angeboten werden. Die am 3. November erscheinende Betaversion von Firefox 43 wird die früheste Betaversion sein, in welcher e10s standardmäßig aktiviert sein wird. Sobald dies der Fall ist, wird Mozilla damit beginnen, Add-ons zu blockieren, die nicht kompatibel mit e10s sind und Performance- und/oder Stabilitätsprobleme verursachen. Am 15. Dezember erscheint dann die finale Version von Firefox 43 und damit die frühestmögliche Version, in welcher e10s aktiviert sein wird. Im Zeitraum von zwischen sechs und zwölf Monaten nach der standardmäßigen Aktivierung von e10s in der finalen Version von Firefox wird Mozilla die Kompatibilitäts-Shims entfernen, womit Add-ons inkompatibel werden, die hiervon Gebrauch machen.
Entwickler von Add-ons sollten sich also so langsam mit der möglicherweise notwendigen Anpassung ihrer Add-ons befassen, falls nicht schon geschehen, und ggfs. das Kompatibilitäts-Flag setzen. Eine Alternative dazu ist natürlich die Portierung zu einer WebExtension. Add-ons können bereits in der Nightly Version sowie Developer Edition mit aktivierter Multiprozessarchitektur getestet werden. Außerdem ist jeder eingeladen, auf der Webseite arewee10syet.com die Liste der Add-ons durchzugehen und die Kompatibilität der Add-os zu testen.
Signierung von Add-ons
An den Plänen zur Signierung von Add-ons hat sich nichts geändert. Add-ons müssen in Zukunft von Mozilla signiert sein, damit sie in Firefox installiert werden können. Damit sollen Nutzer besser vor schädlichen Add-ons und Add-ons, die Dinge gegen den ausdrücklichen Willen des Nutzers machen, geschützt werden. Bislang konnte Mozilla immer nur im Nachhinein reagieren und Add-ons blockieren, nachdem sie bereits Schaden angerichtet haben.
Seit Version 40 warnt Firefox bei nicht signierten Add-ons, ab Version 41 werden diese standardmäßig deaktiviert werden, können aber per Änderung in about:config wieder zum Laufen gebracht werden, ab Firefox 42 ist die Signaturpflicht in der finalen Version und in der Beta unumgänglich. In der Nightly-Version sowie Developer Edition wird die Signaturpflicht auch weiterhin deaktivierbar bleiben. Außerdem wird Mozilla spezielle Beta- und Finalbuilds ohne offizielles Firefox-Branding bereitstellen, welche ebenfalls eine Deaktivierung der Signaturpflicht erlauben.
Schnellere Reviews von Add-ons
Bis Add-ons ein Review von Mozilla erhalten, können schon mal Wochen vergehen – was ohne Frage zu lange ist. Auch hier spielen die neuen WebExtensions einen Vorteil aus, denn diese können wesentlich schneller von Mozilla kontrolliert werden. Ziel sind maximal fünf Tage für ein neues Add-on und maximal zwei Tage für ein Update.
Mozilla wird außerdem das Team der freiwilligen und bezahlten Reviewer aufstocken und weitere Verbesserungen am automatischen Validator vornehmen, um die Wartezeiten zu verkürzen.
Deprecation von XUL, XBL und XPCOM
Eine weitere sehr große Veränderung betrifft die XUL- und XPCOM-basierten Erweiterungen. Dass Mozilla von XUL und XBL abweichen möchte, ist nicht neu. Auch kann Firefox nicht Mozillas kommende Engine Servo nutzen, solange XUL unterstützt wird. Die enge Verzahnung von Browser und XUL-Erweiterungen bereitet außerdem Probleme für die Entwicklung, die in der Ankündigung näher benannt werden.
Für die Deprecation von XUL, XBL und XPCOM gibt es noch keinen genauen Zeitplan, vermutlich wird dies aber innerhalb der nächsten zwölf bis 18 Monate passieren. Ab dann muss man sich darauf einstellen, dass Add-ons, welche Gebrauch von diesen Technologien machen, irgendwann nicht länger funktionieren werden.
Mozilla ist sich dessen bewusst, dass die SDK basierten Add-ons und auch die WebExtensions Stand heute nicht alles leisten können, was XUL-basierte Add-ons leisten können. Basierend auf dem Feedback der Entwickler möchte Mozilla die WebExtensions-API im Laufe des kommenden Jahres aber entsprechend erweitern, um so viel wie möglich zu unterstützen, was von den populären Erweiterungen benötigt wird.
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.
Weitere aktuelle Artikel aus der Kategorie „Firefox“
23 Kommentare - bis jetzt!
Eigenen Kommentar verfassenUnd jetzt du! Deine Meinung?
6 Erwähnungen
- Firefox Add-Ons: Entwicklern stehen größere Änderungen bevor
- Aus Firefox Add-ons werden Webextensions › Horst bloggt
- Mozilla: Große Änderungen für Add-Ons für Firefox und ihre Entwickler angekündigt - Servaholics
- Firefox: Mozilla bittet um Feedback zur Zukunft von Themes
- Mozilla gibt Status-Update zu WebExtensions
- Status-Update zu WebExtensions in Firefox 46
Mir macht das etwas Sorgen, wenn ich ehrlich bin. Nicht wegen Mozilla, den Jungs und Mädels vertraue ich, dass die das gewuppt kriegen. Aber ich hab ein bisschen Bammel, dass die Entwickler von meinen Addons nicht rechtzeitig Updates veröffentlichen, zumindest bis zur finalen Aktivierung von Electrolysis. Bei mir – ich hab mit Firefox 40.0.2 natürlich die aktuellste Version – sind zwar keine Warnungen und alle Addons sind signiert, aber bei den allermeisten war das von Mozilla mit der Signierung gemachte Update halt auch das letzte (wobei bei den meisten das letzte reguläre Update auch erst zwischen März und Mai 2015 gewesen ist, ganz so schlimm ist es also nicht). Ich hoffe schon auf baldige weitere Updates, zumindest würde es meine Sorgen wirklich beruhigen.
Wie gesagt, ich vertraue Mozilla da, aber ich fahre auch die gleiche Schiene wie im letzten Jahr mit Australis und begleite die ganze Thematik mit eigenen Testläufen, um einfach auf Nummer sicher zu gehen. Außerdem ist Google Chrome so eingerichtet, dass er direkt übernehmen könnte, falls die Addons bei Firefox Ärger machen sollten und ich das neu aufbauen muss. Ich glaube, das ist allgemein der richtige Weg, weils ja doch die erste große Änderung seit Australis werden wird.
Unter Linux bin ich aber ziemlich gespannt, das dürfte noch ein lustiges Abenteuer werden. Momentan merke ich das unter unserem Xubuntu-System extrem, wo ich den Browser im Endeffekt in die Tonne treten kann. Wenn ich Firefox da starte, sehe ich bis auf die Titelleiste nur ein leeres graues Fenster, mehr nicht. Was das Problem ist, bin ich mir ziemlich sicher, das zu wissen (einerseits hat Fx 40 OMTC unter Linux eingeführt, andererseits hat Xubuntu immer noch diese tollen Shiny Glanzeffekte, die mir schonmal Ärger gemacht, weil sie die Adressleiste überblendet haben und ich nur einen schwarzen Balken im Textfeld gesehen habe), aber reparieren kann ichs nicht, weil ich dazu in about:config müsste und da komme ich nicht rein, weil ichs nicht sehe… und wenn ich dann noch die Diskussion mitverfolge, warum über das USC kaum Updates verteilt werden (und dass das laut Cannonical noch etliche Monate dauern kann, weil die auf einen neuen Pakettyp umstellen….) und sehe, was bei Firefox bald ansteht… wird mir schlecht…
Wäre gut zu wissen, ob man ein eigenes Repository von Mozilla direkt für Firefox ohne den ganzen Blingbling von Xubuntu einbinden kann, aber dazu hab ich bisher nix gefunden…
Also das Thema e10s ist nun seit Jahren bekannt. Wenn ein Add-on dann noch immer nicht angepasst ist, ja, dann taugt halt entweder der Entwickler des Add-ons nichts oder das Add-on ist schon tot. Ein nicht mehr gepflegtes Add-on muss ja fast irgendwann versagen und irgendwann muss Mozilla auch mal e10s ausliefern. Leider werden bei den meisten Änderungen irgendwelche Add-ons auf der Strecke bleiben, das liegt in der Natur. Doof für die Nutzer dieser Add-ons, aber wohl nicht vermeidbar. 😉
Ich hoffe nur, der Classic Theme Restorer basiert nicht auf XUL^^
Es kostet halt viel Zeit für die Umstellung und nicht jeder hat diese Zeit. Ich hab selbst jetzt seit November an einem einzigen meiner Addons gesessen also 10 Monate. War dann auch gleich Umstellung von XUL Overlay auf Bootstrap. Und auch schön die 5 Jahre alten Bugs (564675, 675372(gefixt in 01/15)) zu sehen für Bootstrap, die immer noch nicht gefixt waren. Vielleicht sollte man so was erst mal machen bevor man die nächste Baustelle aufmacht. Kommentar 23 in Bug 675372 zu Kommentar 20 war Klasse, ja er hat voll und ganz Recht, wenn es erst 5 Jahre später fixt, kommt genau das dabei raus.
Für den Spaß der Signierung gingen die letzten 2 Wochenenden drauf. Onclick attribute waren nicht mehr erwünscht von den Herren und man solle doch Eventlistener nehmen, dann könne man den automatischen Review Prozess mitmachen.
Dachte ok, wenn automatisch nicht geht, lasse ich eben manuell reviewen….nach zwei Tagen gabs ne Email, abgelehnt, überarbeiten. Dafür, daß es erst hieß es ist nur für den automatischen Review notwendig, war ich dann auch kurz vorm platzen. Schließlich waren die Onclick attribute in der Kategorie „medium“ und das manuelle review sollte doch dafür sorgen, das ich keinen Mist mit meinem Addon mache, mehr nicht und das war nun mal nicht der Fall.
Die potentiell ach so gefährlich Onclick Attribute werden auf jeder Website eingesetzt, wie auch, die durch mein Addon auf der Website platzierten Buttons und Links. Und ja, wir sind E10s mit sicherem Framescript und allem was dazugehört. Das zeigt aber es geht hier nicht nur darum böse Addons zu verhindern, sondern auch noch darum das man deren Guidelines fürs coden befolgt, weil man eventuell mit einem onclick attribute noch andere Sicherheitslöcher heraufbeschwören könnte und das geht mir ziemlich gegen den Strich, wenn es offizielle HTML Sachen sind und wir uns immer noch auf ner Website befinden, wo die eingesetzt werden. Das wurde auch vorher nicht so kommuniziert. Community zusammenarbeiten und so…
Der letzte Absatz ist echt gut. Hab mir beim lesen schon einen Kommentar durchüberlegt. Dann nimmst du mir die Worte aus dem Mund.
Dass e10s mittelfristig aber quasi alle alten Add-ons inkompatibel machen wird, ist nicht seit Jahren bekannt.
@Tilman:
Doch. 😉 Aber siehe Artikel von Bill McCloskey:
https://billmccloskey.wordpress.com/2015/08/21/firefox-add-on-changes/
@TheRave:
Wieso nutzt du nicht einfach das Add-on SDK? Damit sind Standard-Einstellungen kein Problem. Dass SDK wird nun schon so lange direkt mit Firefox ausgeliefert, dass SDK-basierte Erweiterungen auch keine nennenswerte Dateigröße mehr besitzen.
Ganz sicher nicht, ich sehe das kaum noch (hab aber auch nicht viel mit schlecht programmierten Webseiten zu tun. 😉 ), die on*-Attribute sind auch in der Webentwicklung ganz schlechter Stil, man nutzt üblicherweise Eventlistener. Vor allem die Popularität von jQuery dürfte dazu beigetragen haben, dass man eigentlich fast nur noch das sieht, denn das kommt ja wirklich auf den meisten Webseiten zum Einsatz.
@Anon:
Doch. Sogar schon im ersten Anlauf, bevor die ersten e10s-Bemühungen auf Eis gelegt worden sind, ehe man es später neu in Angriff genommen hat, war klar, dass e10s starke Auswirkungen auf die Kompatibilität von Add-ons haben wird und Add-ons (und Plugins) eine der größten Hürden sind. Das wurde auch seit Beginn der Wiederaufnahme der e10s-Arbeit von Anfang an kommuniziert. Das ist also seit Jahren bekannt.
„Alle alten Add-ons“ müsste natürlich zunächst definiert werden. Viele Add-ons benötigen keine Anpassungen. Ich musste beispielsweise kein einziges meiner Add-ons anpassen, weil es sich um SDK-basierte Add-ons handelt, die sind automatisch kompatibel.
Ich kann keine Fragen zum ‚wie‘ beantworten, damit habe ich mich nicht beschäftigt. Ich war nur am ‚was‘ interessiert. 😉
Der Entwickler von DownloadThemAll! hat übrigens schon gesagt, dass er keine großen Chancen sieht mit der neuen API sein Addon fortzusetzen. Na klasse!
@Anon: Damit hat der Entwickler nur gezeigt, dass er nicht lesen kann. Es wurde ganz klar kommuniziert, dass Mozilla die APIs je nach Bedarf erweitern wird. Und: wieder aus dem Artikel von Bill McCloskey:
An dem sollte sich der mal ein Beispiel nehmen. Der NoScript-Entwickler jammert nie, der zeigt sich immer produktiv, kommuniziert mit Mozilla und profitiert am Ende, weil er das bekommt, was er für sein Add-on benötigt. Gerade wenn man ein populäres Add-on anbietet ist Mozilla immer sehr interessiert an einer Zusammenarbeit, damit die Add-ons auch weiterhin funktionieren, sah man bei Australis schon, sieht man bei e10s und jetzt hier.
Auch lesenswert: der Artikel vom NoScript-Entwickler:
https://hackademix.net/2015/08/22/webextensions-api-noscript/
Lächerlich….
http://www.downthemall.net/the-likely-end-of-downthemall/
@Antares: Nutzt Du den proprietären AMD-Grafiktreiber? Ich bin vor einem Jahr aus dem Grund auf den freien „radeon“-Treiber umgestiegen. Auch wenn nicht, ich kann Dir vielleicht wegen des leeren Fensters helfen. Schreib mich mal bei @cyberfrumble an.
@bla: Ja, das ist lächerlich, was der Entwickler dieses Add-ons schreibt. Aber es ist leider so, dass es auf der einen Seite die Entwickler von Add-ons wie NoScript oder Adblock Plus gibt, die immer auf der Höhe der Zeit sind und sich darum kümmern, dass sie mit Mozilla diskutieren, was sie benötigen, ihre Add-ons dann auch anpassen, während es auf der anderen Seite Entwickler gibt, die eingeschnappt sind, dass Firefox weiterentwickelt wird und sie etwas anpassen müssen und in der Folge das Handtuch werfen. Der Leidtragende ist der Nutzer. Natürlich ist das nicht optimal. Aber was will man machen… in dem Fall kann man nur auf Alternativen hoffen.
Auch der Adblock Plus Entwickler ist wenig begeistert..
https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/comment-page-1/#comment-218678
Das hat nichts mit eingeschnappt zu tun. Wen man nur am Wochenende Zeit hat kann man nicht jeden Schnack mitmachen ist doch logisch. Da macht man das nötigste um alles am laufen zu halten und das wars. Noch dazu gibts, dann Sachen die nicht mehr gehen oder nur mit massiv Aufwand, wenn überhaupt und wenn man gerade fertig ist kommt der nächste Hammer, was natürlich für eine Top Motivation sorgt.
Und das mit Futures nachbestellen durch Dialog mit Mozilla. Erst mal kommt nur das rein, was den Firefox Entwicklern in den Kram passt. Und das gilt ganz besonders für APIs. Und zu anderen Future wünschen, wie schrieb ein Firefox Entwickler damals so schön, das ist hier keine Demokratie…jupp.
Prominente Addon Entwickler der bekanntesten Addons haben natürlich nicht nur viel Ahnung von dem was die da machen, sondern vor allem auch eine Menge Nutzer ihrer Addons. Das sind schon mal zwei gewichtige Argumente um seine Wünsche auch durchzubringen. Hier solltest man nicht Äpfel mit Birnen vergleichen. Das trifft wohl nur auf die wenigsten Addon Entwickler zu.
SDK nutze ich übrigens ungern. Man ist daran gebunden was das SDK hergibt. Was nicht geht muss man zu Fuss erledigen. Dann mache ich lieber alles zu Fuß. Ich hab jetzt das erste mal die child_process API eingebaut aus dem SDK weil die das hatte was ich brauchte. Zudem habe ich auch schon SDK Versions wechsel gesehen, die „Arbeit“ machten für die Addonentwickler und wenn sich da ein Bug einschleicht muss auch dieser erstmal gefixt werden, man ist dann auch auf andere angewiesen.
Warten wir es ab. Würde nur endlich gern das Redesign von Panarama mit der angefragten API sehen, wo die Entwickler ja nun auf unsere Wünsche eingehen sollte das ja kein Problem mehr sein, schließlich wird das Addon was ich dafür nutze auch in 18 Monaten nicht mehr funktionieren und bis dahin muss ich Ersatz haben. Werde ich aber wohl eher nicht…
@Maxi
Ja, das ist der normale AMD-Treiber. Ich habe Xubuntu (in meinem Fall die 14.04 LTS-Version) mehr oder weniger „out of the box“ gelassen und nicht sehr viel selber angepasst, weil das Linux zunächst nur als Ersatz für Windows XP dienen sollte (der Rechner wurde kaum benutzt, aber mit auslaufendem Support musste Ersatz her, wobei der Rechner auch die 12.04 LTS schon hatte) und ich es quasi auch als Lernplattform für Linux benutze, weil ich neben meinem Arbeitsrechner mit (jetzt) Windows 10 auch noch meinen Laptop mit einem Linuxsystem austatten will, damit ich beide Systeme nutzen kann.
Wie gesagt, Ärger bei Firefox hatte ich schon einmal und da war es ein Grafikeffekt, den ich in about:config abschalten musste, etwas Ähnliches vermute ich auch diesmal, weil das erst seit Firefox 40 so ist und in dieser Version ja OMTC unter Linux eingeführt wurde. Momentan bin ich auch stark am Überlegen, ob im nächsten Jahr Xubuntu 16.04 LTS installieren soll (ich hatte mir eigentlich vorgenommen, jede neue LTS-Version zu nutzen) oder ob ich einen anderen Weg gehe: Entweder direkt zu Debian, auch um vom USC unabhängig zu werden, oder via Arch mein Linuxsystem komplett selbst zusammenzustellen. Das weiß ich noch nicht. Jedenfalls glaube ich, dass es besser gewesen wäre, ein Repository von Mozilla direkt einzubinden als der Standardinstallation mit den entsprechenden Ubuntu-Anpassungen zu vertrauen. Soviel ist sicher…
@bla:
Muss er ja auch nicht. Der Punkt, was ich in meinem vorherigen Kommentar schon meinte: er kommuniziert mit Mozilla auf Bugzilla, hat auf seinem Blog gutes Feedback geschrieben, so ist das in Ordnung und bringt alle weiter. Im Unterschied dazu könnte man auch einfach nur meckern und nichts sinnvoll beitragen. Aber davon hat ja niemand was.
@TheRave:
Du sprichst von dir, ich habe meinen Beitrag aber keinesfalls auf dich bezogen. Ich bin nun schon einige Jahre dabei und ich habe schon einige eingeschnappte Entwickler-Reaktionen erlebt. Und darauf beziehe ich das. Es gibt die Entwickler, die eingeschnappt reagieren und das Handtuch werfen und da geht es nicht unbedingt in erster Linie um Zeit. Die Zeit spielt in vielen Fällen mit Sicherheit auch rein, dennoch kann man auf eine positive oder auf negative Weise reagieren.
Das bestreitet absolut niemand. Zeit ist glaube ich für jeden ein kostbares Gut. 😉
So ist es ja nun wirklich nicht. Für einzelne Add-ons vielleicht, die wirklich komplex sind. Ich kann mir schon vorstellen, dass die Pflege eines Add-ons wie Tab Mix Plus extrem aufwändig sein muss. Aber das klingt so, als seien generell permanent große Änderungen notwendig. Aber hier geht’s a) um Signierung: keine wirkliche Anpassung notwendig b) e10s: seit vielen Jahren bekannt und c) um WebExtensions / XUL-Deprecation: eine sehr rechtzeitige Ankündigung, Entwickler müssen ihre Add-ons nicht innerhalb von zwei Wochen anpassen und sie können sogar noch die APIs durch Feedback mitgestalten. Plötzliche Panik halte ich daher für unangebracht.
Selbstverständlich ist das keine Demokratie, das könnte überhaupt nicht funktionieren. Das sehe ich jeden Tag im Firefox-Forum, wie unterschiedlich die Ansprüche von jedem einzelnen sind. Und natürlich gibt es Entscheidungsträger bei Mozilla, die die Verantwortung tragen. Dennoch ist ein Dialog sinnvoll und wer die Chance nicht nutzt, selbst Schuld.
Ich habe keine Ahnung, worauf du die Äpfel und Birnen beziehst, aber selbstverständlich hat es mehr Gewicht, was ein Add-on mit 20 Millionen Nutzer benötigt als etwas, was einzig und allein von einem Add-on mit fünf Nutzern benötigt wird. Aber wenn die größten Add-ons mit WebExtensions umgesetzt werden könnten, dann dürfte das schon eine ganze Menge abdecken, wovon auch andere profitieren.
Die Alternative dazu wäre, die Entwicklung des Add-on-Systems einzustellen und keine neuen Möglichkeiten für Entwickler zu schaffen. Also klar kann es auch da zu Inkompatiblitäten kommen, das gab es immer und wird es immer geben, das ist nicht vermeidbar.
Die eigentlich interessante Frage ist ja auch: Wie wird Thunderbird darauf reagieren?
Es ist ja nunmal Fakt, dass sich Firefox ESR und Thunderbird die gleiche Basis teilen und da isses nunmal naheliegend, dass Thunderbird auch die WebExtensions bekommen wird. Man kanns da keinem Addon-Entwickler übel nehmen, wenn er sagt, dass er in seiner Freizeit lieber das Addon für einen Browser, den je nach Hochrechnung zwischen 400 und 500 Millionen Menschen nutzen, portiert und pflegt, anstatt dies für einen Mailclient mit rund 20 Millionen Nutzern (auch) zu tun, sofern sein Addon überhaupt dort einsetzbar ist. Die Zahl der aktiv entwickelten Addons ist gefühlt in den letzten 3 Jahren, seitdem Thunderbird ein reines Communityprojekt ist, eh schon stark zurückgegangen. Da bleibt dann abzuwarten, ob der T-Bird da nicht als „Kollateralschaden“ auch angeknockt wird und die Zahl der Addons nicht weiter sinken wird.
Versteht mich nicht falsch, ich begrüße die Änderungen von Mozilla. Allerdings befindet sich die neue Entwicklercommunity rund um Thunderbird immer noch mehr oder weniger in der Findungsphase (ist ja gerade mal ein knappes Jahr her seit der Neuformierung) und es wird in meinen Augen auch mit der Hilfe von SoftMaker schwer, diese Herausforderung zu stemmen. Mozilla selber leistet ja keine Hilfestellung mehr und gerade bei Windows 10 hat der T-Bird momentan noch so seine Problemchen, wenn ich mal daran denke, dass die Personas (ich hab den aktuellen Namen der Minithemes schon wieder vergessen… 😀 ) wegen der fehlenden Anpassungen, die Firefox ja hat, richtig kaputt aussehen.
@Antares:
Die Änderungen betreffen Thunderbird alle erst einmal nicht, langfristig lässt sich das noch nicht sagen. Das wird auch ganz stark davon abhängen, was Mozilla macht. Jede größere Abweichung von Firefox ist ein Problem.
Die dazugehörige Diskussion:
https://groups.google.com/forum/?fromgroups=#!topic/tb-planning/UIVHTbhjrU8
Nicht notwendigerweise, siehe SDK-Erweiterungen. Natürlich braucht Thunderbird eine Lösung, wenn XUL irgendwann ganz weg aus der Codebasis ist. Aber das ist noch vollkommen unklar, das wird die Zukunft erst zeigen.
Kann ich nicht beurteilen, ich nutze nicht ein einziges Add-on in Thunderbird. 😉
Einfach nur Themes. Oder wenn du das ausdrücklich von kompletten Themes unterscheiden willst: Lightweight Themes. 😉