So geht es weiter mit dem Multiprozess-Firefox – 2. Edition
Die neue Multiprozess-Architektur Electrolysis, kurz: e10s, erreicht immer mehr Nutzer. Es handelt sich dabei um den größten Umbau von Firefox, seit es den Mozilla-Browser gibt. Dieser Artikel gibt einen aktuellen und ausführlichen Überblick darüber, was die nächsten Meilensteine hinsichtlich der Multiprozess-Architektur sind.
Unter dem Namen Electrolysis, oder kurz: e10s, entwickelt Mozilla eine Multiprozess-Architektur für Firefox. Eine finale Version hat diese erstmals mit Firefox 48 erreicht; damals noch in der einfachsten Form mit nur einem Content-Prozess und nur für einen kleinen Teil der Nutzer. Unter anderem durften keine Add-ons aktiviert sein, damit die Multiprozess-Architektur aktiviert wird.
Vor einem halben Jahr wurde auf diesem Blog eine ausführliche Zusammenfassung über die kommenden Meilensteine der Multiprozess-Architektur veröffentlicht und seitdem aktuell gehalten. Zwecks Übersichtlichkeit folgt an dieser Stelle eine neue Zusammenfassung mit den aktuellen Planungen, welche damit die alte Übersicht ablöst.
Grundsätzlich gilt, dass – wenn im Folgenden auch bei keiner bestimmten Firefox-Version explizit erwähnt – mit jeder neuen Version an Faktoren wie Performance und Stabilität gearbeitet wird und die Multiprozess-Architektur besser funktionieren sollte als mit der jeweiligen Version zuvor. Unter anderem das Wechseln von Tabs in Kombination mit e10s konnte zwischen Firefox 48 und Firefox 53 spürbar verbessert werden.
Firefox 51: Der aktuelle Stand der Dinge
Die Multiprozess-Architektur aktiviert in Firefox 51 neben einem Browser-Prozess standardmäßig einen einzelnen Content-Prozess, den sich alle Tabs teilen. NPAPI-Plugins laufen bereits seit lange vor dem e10s-Projekt in einem eigenen Prozess, dem sogenannten Plugin-Container. Die Aufteilung auf weitere Prozesse ist für eine spätere Version geplant.
Damit die Multiprozess-Architektur in Firefox 51 aktiviert wird, müssen verschiedene Kriterien erfüllt werden. Ein Kriterium sind die aktivierten Add-ons. Folgende Erweiterungen qualifizieren für die Nutzung von e10s: ausnahmslos alle WebExtensions, alle Erweiterungen, welche von ihrem Entwickler explizit als kompatibel markiert worden sind (Ausnahme: Tab Mix Plus) sowie an die 770 weitere Erweiterungen, die auf dieser Liste stehen.
Es genügt ein einzelnes aktiviertes Add-on, welches diese Anforderung nicht erfüllt, damit die Multiprozess-Architektur deaktiviert bleibt. Weitere Ausschlusskriterien: die Verwendung von Microsoft Windows XP als Betriebssystem, von Screenreadern oder anderen a11y-Werkzeugen, von Geräten mit Touchscreen sowie von Firefox auf Linux in einer Sprache, in welcher von rechts nach links geschrieben wird.
Firefox 52: Linux + RTL-Sprachen
Mozilla hat die Unterstützung von e10s + Firefox in Sprachen, in denen von rechts nach links geschrieben wird, in Firefox 50 aktiviert – für Nutzer von Windows und macOS. In Firefox 52 kommt die entsprechende Linux-Unterstützung dazu.
Firefox 52: Unterstützung von userContent.css
Firefox besitzt ein mächtiges Werkzeug von Haus aus integriert, welches es ermöglicht, die Gestaltung von Webseiten nahezu beliebig zu beeinflussen, zumindest im Rahmen dessen, was mit CSS möglich ist. Eine Erweiterung wie Stylish ist also für Firefox-Nutzer häufig gar nicht notwendig, wenn die Optik einer Webseite geändert werden soll. Gemeinsam mit der Multiprozess-Architektur konnte dieses Feature bisher allerdings nicht genutzt werden. Ab Firefox 52 werden e10s + userContent.css unterstützt.
Firefox 52+: Kompatibilität mit weiteren Add-ons
Seit Veröffentlichung von Firefox 48 wurde die Kompatibilität von e10s + Add-ons mit jeder weiteren Version erweitert. Dies soll auch in Firefox 52 wieder der Fall sein. Unter anderem wird Tab Mix Plus von der Blacklist genommen, womit dessen Nutzung nicht mehr für die Nutzung von e10s disqualifiziert.
Die Ausrollung für Nutzer weiterer Add-ons basiert auf dem Verlauf der Betaphase und den Daten, die sich im Laufe der kommenden Wochen und Monate ergeben. Schlussendliches Ziel ist es, dass alle Erweiterungen für die Nutzung von e10s qualifizieren, welche von ihrem Entwickler nicht explizit als nicht kompatibel markiert worden sind. Im Idealfall sollte dies mit Firefox 53 der Fall sein.
Unabhängig von Änderungen durch Mozilla können natürlich auch weitere Add-ons von ihren jeweiligen Entwicklern im Laufe der kommenden Monate als e10s-kompatibel markiert werden.
Spezialfall: Firefox ESR 52
Firefox ESR steht für Extended Support Release und bezeichnet die Firefox-Version, die mit Langzeitunterstützung kommt. Das bedeutet, dass diese Version nur einmal im Jahr einen großen Versionssprung macht und dabei sehr viele Neuerungen erhält, dazwischen gibt es alle sechs bis acht Wochen lediglich Bugfix- und Sicherheitsupdates.
Für Firefox ESR gilt bei der Ausrollung von e10s eine Besonderheit: zum Einsatz kommen nicht die Kriterien der Mainstream-Version von Firefox 52, sondern die von Firefox 50. Das heißt, die in Firefox 51 rund 770 zusätzlich unterstützten Erweiterungen werden in Firefox ESR 52 genauso wenig unterstützt wie Tab Mix Plus und alle weiteren Erweiterungen, welche noch in der finalen Version von Firefox 52 für die Nutzung mit e10s erlaubt werden.
Ausnahme zu den Kriterien von Firefox 50: Nutzer der russischen Firefox-Version werden in Firefox ESR 52 nicht von der Nutzung der Multiprozess-Unterstützung ausgeschlossen (diese Restriktion wurde ursprünglich in Firefox 51 aufgehoben).
Kein e10s für Nutzer von Windows XP
Mozilla stellt die Unterstützung von Windows XP mit Firefox 52 ein. Entsprechende Nutzer werden dann automatisch auf Firefox ESR 52 migriert werden und noch zumindest bis September 2017 Sicherheitsupdates erhalten. Firefox 53 und neuer werden auf Systemen mit Windows XP gar nicht erst starten. Aber auch in Firefox ESR 52 erhalten Nutzer von Windows XP kein e10s. Mit anderen Worten: Nutzer von Windows XP werden nie Firefox mit Multiprozess-Architektur erhalten.
Firefox 53: GPU-Prozess für Windows-Nutzer
Der Quantum Compositor ist kein Teil der e10s-, sondern der Quantum-Initiative, nichtsdestominder sei dies hier erwähnt, weil der Quantum Compositor einen zusätzlichen Grafikkarten-Prozess einführt. Da Grafiktreiber eine der Hauptursachen für Firefox-Abstürze sind, wird durch die Auslagerung in einen eigenen Prozess erwartet, dass Firefox dadurch wesentlich stabiler wird. Der zusätzliche Prozess soll in Firefox 53 für Windows-Nutzer standardmäßig aktiviert sein.
Firefox 53: Neue Add-ons dürfen nur noch WebExtensions sein
Ab dem Tag des Erscheinens von Firefox 53 akzeptiert Mozilla auf addons.mozilla.org nur noch neue Erweiterungen, welche WebExtensions und damit automatisch e10s-kompatibel sind, nicht länger XUL- oder SDK-basierte Erweiterungen. Dies gilt auch für die Signierung von Erweiterungen, die auf anderen Seiten gehostet werden. Bereits existierende Erweiterungen alter Architekturen können weiterhin bis zum Erscheinen von Firefox 57 auf neue Versionen mit ebenfalls alter Architektur aktualisiert werden.
Firefox 53: Blockierung falsch markierter Add-ons
Hat der Nutzer Add-ons aktiviert, welche von ihrem Entwickler explizit als kompatibel markiert worden sind, ist damit eine wichtige Bedingung für die Aktivierung der Multiprozess-Architektur erfüllt. Genauso kann ein Entwickler eine Erweiterung als nicht kompatibel markieren, dann bleibt die Erweiterung aktiv und die Multiprozess-Architektur deaktiviert. Ist allerdings ein Add-on als kompatibel markiert und ist reproduzierbar nicht kompatibel, wird das jeweilige Add-on ab Firefox 53 deaktiviert und die Multiprozess-Architektur nicht wegen dieses Add-ons deaktiviert.
Firefox 54: Gestaltung von Optionsfeldern per CSS
Die Optionsfelder von <select>-Elementen waren schon immer schwierig browser- sowie betriebssystemübergreifend zu gestalten. Hatte Firefox dies in der Vergangenheit erlaubt, war das mit aktivierter Multiprozess-Architektur bislang nicht mehr möglich. Ab Firefox 54 können hier wieder die Hintergrund- sowie Textfarbe per CSS geändert werden. Andere Änderungen per CSS werden nicht unterstützt.
Firefox 54+: Sandboxing
Ebenfalls für Firefox 54 geplant ist die erstmalige standardmäßige Erweiterung von Firefox um sogenanntes Sandboxing der Content-Prozesse. Dies soll Firefox sicherer machen. Die Multiprozess-Architektur ist hierfür eine Voraussetzung. In weiteren Versionen können die Sandbox-Restriktionen weiter verschärft werden.
Firefox 55: Unterstützung von a11y-Werkzeugen
Ab Firefox 55 werden erstmals a11y-Werkzeuge gemeinsam mit e10s unterstützt. Darunter fallen Tools wie Screenreader, Bildschirmlupen, aber auch Geräte mit Touchscreen.
Firefox 55: Mehrere Content-Prozesse
In der Nightly-Version von Firefox 54 sind bereits zwei Content-Prozesse statt nur einem standardmäßig aktiviert. Mozilla arbeitet daran, mehrere Content-Prozesse über Nightly-Versionen hinaus kompatibel zu machen und plant mit vier Content-Prozessen für den Anfang. Geplante Auslieferung in einer finalen Version: Firefox 55.
Firefox 55: WebExtensions in eigenen Prozessen
Darüber hinaus arbeitet Mozilla bereits daran, WebExtensions in eigene Prozesse auszulagern. Auch hier wird mit Firefox 55 als Ziel für die Auslieferung in einer finalen Version geplant.
Firefox 57: keine inkompatiblen Erweiterungen mehr
Ab Firefox 57 werden nur noch WebExtensions unterstützt, weder alte XUL-Erweiterungen noch SDK-basierte Erweiterungen. Damit gibt es ab Firefox 57 auch keine Erweiterungen mehr, welche nicht kompatibel mit e10s sind. In Firefox vorhandene Kompatibilitäts-Shims, welche die Umstellung von Erweiterungen alter Architekturen bei Verwendung auf Kosten der Performance erleichterten, werden ab Version 57 aus Firefox entfernt werden.
Hinweis für Nutzer der Beta-Version von Firefox: Es besteht die Möglichkeit, dass diese Einschränkung bereits während der Beta-Phase von Firefox 56 getestet werden wird.
Firefox 57 (Nightly): Entfernung der Option, e10s zu deaktivieren
Firefox 57 erreicht im Juni die Nightly-Phase. Geplant ist, dass ab dann e10s in der Nightly-Version auch nicht mehr deaktiviert werden kann. Ob dies bereits die finale Version von Firefox 57 betreffen wird, ist noch nicht bekannt.
Firefox.next: weitere Prozesse
Die Nightly-Version von Firefox hat bereits seit Version 53 einen eigenen Content-Prozess für den lokalen Dateizugriff per file://-URI standardmäßig aktiviert. Diese Maßnahme dient der Sicherheit. Sollte durch ein Sicherheitsproblem ein Content-Prozess kompromittiert werden, kann dieser dadurch trotzdem nicht genutzt werden, um auf lokale Dateien zuzugreifen. Dieser spezielle Content-Prozess besitzt ausschließlich Lese-Rechte auf dem System. Wann dieser zusätzliche Prozess in der finalen Version von Firefox standardmäßig aktiviert werden wird, ist noch nicht bekannt.
Auch die Aktivierung von mehr als vier Content-Prozessen ist langfristig denkbar. Konkrete Zielsetzungen oder Pläne gibt es diesbezüglich aber noch nicht.
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.
Was für einen Vorteil bringt Sandboxing denn für die Sicherheit? Bei Chrome läuft
ja auch jeder Prozess in einer Sandbox, trotzdem ist der Browser nicht unbedingt sicherer als Firefox
Vielleicht ist Chrome nicht sicherer als Firefox (weiß ich nicht, das soll jemand anderes beurteilen), aber in jedem Fall ist Chrome mit Sandboxing sicherer als Chrome ohne Sandboxing.
Der Vorteil einer Sandbox ist, dass wenn ein Teil der Anwendung kompromittiert wird, in dem Fall ein Content-Prozess, damit kein größerer Schaden angerichtet werden kann. Eine Sandbox schränkt, vereinfacht gesagt, die Rechte ein, die ein Prozess hat. Das kann bedeuten, dass ein Prozess nur Leserechte, aber keine Schreibrechte besitzt, das kann auch bedeuten, dass ein Prozess auf bestimmte Bereiche des Systems überhaupt keinen Zugriff hat.
Denke im 1. SATZ zu Firefox 52 hat sich ein Fehler eingeschlichen. Da ist ein "er" zu viel.
Danke, Fehler ist korrigiert!
Beim Lesen des Artikels beschleicht mich ein ungutes Gefühl. Spätestens seit der Umstellung auf die Australis Oberfläche läuft beim Firefox einiges in die falsche Richtung. Bisher kann man das mit diversen Addons zurückbiegen und den Browser wunschgemäß anpassen. Mit Version 57 werden viele beliebte Erweiterungen nicht mehr funktionieren. Das dürfte für reichlich Unmut sorgen.
Grüße
Keine Ahnung, was du damit meinst. Australis war eine gelungene Modernisierung, die Firefox dringend notwendig hatte. Metriken zur Nutzung von Firefox belegen, dass Australis Firefox nicht geschadet hat. Und außer Australis nennst du nichts, was in eine vermeintlich falsche Richtung gehen würde.
Zahlreiche Add-ons sind bereits angepasst oder werden noch angepasst, nicht jedes Add-on wird angepasst werden (auch nicht können), dafür kommen wieder neue Erweiterungen. So war es schon immer und so wird es immer sein, Erweiterungen und auch Erweiterungs-Entwickler kommen und gehen. Ich selbst werde vermutlich diesen Monat meine nächste Firefox-Erweiterung veröffentlichen, meine zweite WebExtension. Die Entwicklung von WebExtensions ist ein großer Fortschritt gegenüber älteren Architekturen – das ist meine Meinung als Erweiterungsentwickler. Auch, wenn vieles nicht möglich sein wird – absichtlich nicht. Aber das ist nicht unbedingt schlecht. Firefox selbst profitiert davon.
Die aktuelle Architektur für Addons ist eben relativ unsicher, zu langsam und steht aktuellen Entwicklungen bei Mozilla im Weg. XUL weiter zu unterstützen wäre mittelfristig der Tod von Firefox, weil alles andere damit stagnieren würde. Wer Firefox weiter benutzen will, sollte das abseits einer zweifelhaften "ich will aber!"-Einstellung also sehr begrüßen.
Auch die Forks werden es sich nicht leisten können, XUL ohne deutliche Abstriche bei Kompatibilität, Performance und Sicherheit weiter zu unterstützen – zumal diese noch mehr Nischenanwendungen sind.
Addons haben den Firefox nie ausgemacht, auch wenn das ein sehr netter Bonus war. Im Kern sehe ich Firefox als offenen Browser einer Non-Profit-Organisation, die sich einem offenen Web verschrieben hat. Die sogenannten Poweruser sind nur ein kleiner Teil der potentiellen Userschaft.
Natürlich werde auch ich manch liebgewonnenem Addon hinterher weinen. Das widerspricht oben Gesagtem nicht. Im Gegenteil, wir reden hier über das Web. Eine immer noch junge, sehr wandelbare Technologie.
Kurze Frage: Wenn ab Firefox 54 Touchscreens unterstützt werden, betrifft das nur PCs (wie 2-in-1-Convertibles) oder bezieht das auch Smartphones ein? Weißt du das reinzufällig?
Und wenn ich schonmal einen Kommentar schreibe, möchte ich auch kurz die gute Arbeit hier würdigen: Ich finde die Webseite sehr gelungen und die Texte auch für Laien recht verständlich geschrieben! 🙂
Ich bin gespannt. Ich habe e10s erzwungen (ein Anti-Alias Tuner AddOn wird für inkompatibel gehalten) und der Browser fühlte sich wie neu an. Gerade aufwändige Webseiten ruckelten trotz potentem Rechner und Grafikkarte gern mal. Nach e10s war das Geschichte. ?
Einzig mein AddOn für eine bessere Schriftglättung werde ich wohl vermissen. Die Standardglättung ist unter Windows leider eher suboptimal doch eine Webextension leider noch nicht in Sicht. Klar kann man die Änderungen auch direkt in der about:config vornehmen aber dazu müsste ich erst einmal herausfinden, wie die Einstellungen heißen… ?
Ich blicke daher durchaus positiv in die Zukunft des Fuchses. Performanz und Stabilität waren in der Vergangenheit eher die Schwachpunkte, daher bin ich froh, dass nun so konsequent daran gewerkelt wird. ?
@Aljoscha:
Wenn hier von der Multiprozessarchitektur Electrolysis / e10s die Rede ist, dann geht es um den Desktop-Firefox, das heißt Firefox für Windows, Apple macOS sowie Linux. Was für ein Gerät genutzt wird, spielt dafür keine Rolle, sondern nur das Betriebssystem. Smartphones nutzen aber üblicherweise sowieso ein anderes Betriebssystem.
Danke!
@Nils:
Wenn Einstellungen zu ändern das einzige oder zumindest Hauptaufgabe des Add-ons ist, dann wird es das auch vermutlich nie als WebExtension geben, denn WebExtensions dürfen ganz bewusst keine Einstellungen mehr verändern, die über about:config verändert werden.
Hast du die ClearType-Einstellungen mal angepasst? IMO hat Firefox unter Windows noch die beste Schriftglättung aller Webbrowser, aber da sind die Meinungen ja geteilt.
Danke für die Aktualisierung! Für neue Leser wäre es aber nett zu sagen, woran sie erkennen, ob e10s aktuell (de-)aktiviert ist.
@blub:
Ist Nils oder ich gemeint? 😀 Denn ich nutze kein Windows. 😉
@Guido:
Unter about:support das Feld "Fenster mit mehreren Prozessen".
Nils war gemeint 😀
@blub
Das trifft den Nagel ziemlich auf den Kopf, aber man muss dennoch zwei Sachen im Hinterkopf behalten. Zum einen sehe ich in den Forks eigentlich nicht den Kernpunkt. Während die kommerziellen Vertreter noch relativ zahlreich vorhanden sind, sterben die reinen Communityvertreter, die auf Firefox basieren, seit einiger Zeit kontinuierlich weg. Lassen wir Thunderbird mal außenvor, siehts düster aus: SeaMonkey mit großen Problemen, Nightingale wurde eingestellt, Instantbird ist auch mehr oder weniger tot, von K-Meleon hörste auch fast nix mehr und so weiter.
Das andere, wirkliche Thema sind die Addon-Entwickler, die krampfhaft an XUL und den alten Technologien festhalten und die neuen WebExtensions nicht mittragen wollen. Mich würds persönlich nicht wundern, wenn die es sich einfach machen und einfach zu Pale Moon abwandern. Goanna, der Pseudo-geniale Fork von Gecko, wird XUL und das ganze Altmetall ja weiter unterstützen. Man merkt, dass die Schere in der OSS-Gemeinde zwischen denen, die einen Status Quo erhalten und halbwegs konservieren wollen, und denen, die am ursprünglichen OSS-Gedanken festhalten und eine moderne Alternative zu kommerzieller/etablierter Software bieten wollen, immer weiter auseinandergeht.
Zum Thema:
Firefox hat bei mir mit dem letzten Update Electrolysis auch endlich aktiviert und es fühlt sich schon jetzt verdammt gut an. Momentan springe ich sehr zwischen Chrome und Firefox hin und her, weil beide in bestimmten Punkten ihre Vor- und Nachteile haben, aber ich hoffe inständig, dass Mozilla wirklich alles von dem, was sie sich für dieses Jahr vorgenommen haben, auch umsetzen können. Firefox ist einfach zu wichtig, damit die Chromium- und Blink-Riege langfristig einen starken Gegenpol bekommt, der auf allen Plattformen zuhause ist. Mir gehts da nicht unbedingt um die großen Features (ich hätte nichts dagegen, wenn es Pageshot und Minvid so oder so ähnlich als richtige Features in Firefox schaffen, das nur so nebenbei 😉 ), aber wer, wenn nicht Firefox, soll den Wettbewerb gegenüber Chrome wieder stärker anheizen? Vivaldi und Opera sind zwar populärer geworden, aber Vivaldi mangelt es noch an grundlegenden Features und hinter Opera steht innerhalb des chinesischen Konsortiums mittlerweile Qihoo, die schon mehrfach, zuletzt ja durch WoSign und Startcom, negativ aufgefallen sind. Insofern hoffe ich einfach mal, dass besonders Electrolysis und Quantum ihre Wirkung nicht verfehlen.
Bitte zwei Sachen nicht in einen Topf werfen: Anwendungen wie Thunderbird, Nightingale, Instantbird oder K-Meleon haben mit Firefox nichts zu tun. Sie basieren auf der gleichen Plattform namens Gecko. Das ist nicht gleichbedeutend damit, dass diese Anwendungen auf Firefox basieren würden.
Und es ist nun wirlich keine Neuigkeit mehr, dass Mozilla bereits mit Firefox 4 das Kapitel Embedding von Gecko beendet hat. Ergo ist das alles andere als trivial und nicht vergleichbar mit Dingen wie dem Chromium Embedded Framework oder Electron, die es wirklich einfach machen, Chromium einzubetten.
Ausgerechnet Pale Moon? Das ergibt nicht wirklich Sinn. Selbst Firefox unterstüzt noch alle Erweiterungs-Architekturen, da gibt es frühenstens im November 2017 den großen Einschnitt. Pale Moon hingegen unterstützt nicht erst seit heute nicht einmal mehr das Add-on SDK. Und darauf basieren extrem viele Erweiterungen, einschließlich meiner Erweiterung New Tab Override, welche für so viele Nutzer unverzichtbar ist. Wer Wert auf Add-ons legt, für den kann Pale Moon keine Alternative sein. Zumal Pale Moon ja vermutlich auch keine WebExtensions unterstützen wird und damit entfallen auch wieder so viele tolle Firefox-Erweiterungen, die für Pale Moon nicht verfügbar sein werden. Einschließlich meiner kommenden Firefox-Erweiterung, deren Name ich an dieser Stelle noch nicht verraten werde. 😉
Am Können wird es vermutlich nicht scheitern. Allerdings muss man bei Mozilla immer damit rechnen, dass alles wesentlich länger dauert als ursprünglich gewünscht. 😀
Wenn ich da etwas richtig verstanden habe, wird Page Shot den Weg in Firefox finden. 😉
Was heißt nicht wollen, vieles wird nunmal einfach nicht mehr möglich sein mit WebExtensions. Alle interfacemodifizierenden Addons sind praktisch DoA. Es gab auch durchaus bekannte Addonentwickler, die den Schritt mitgehen wollten (Quicksaver bspw.), aber einsehen mussten, dass Mozilla weder den Willen noch die Möglichkeiten hat, die nötigen APIs zur Verfügung zu stellen.
Das können sie ja gerne machen, ich sehe da aber keine Zukunft.
Vivaldi und Opera basieren beide auf Chromium und sind damit grundlegenden politischen Entscheidungen von Google ausgeliefert. Chromium kann noch so sehr open source sein, letztlich gibt Google die Marschrichtung vor.
Umso wichtiger, dass ein starker Firefox bestehen bleibt. Ich finde es eher Besorgnis erregend, mit wie viel Missfallen und Spott Mozilla heute bedacht wird. Sowohl in der Fachpresse als auch bei normalen Usern. Die Mission, die Mozilla als einziger Browserhersteller, der keinem großen Konzern angehört, immer noch verfolgt, scheint mittlerweile niemanden mehr zu interessieren.
Ich kann es auch nicht am Produkt festmachen, denn im großen Ganzen ist Firefox heute zweifellos ein bedeutend besserer Browser als zu seinen Hochzeiten.
Das scheint sehr individuell zu sein, denn für mich trifft genau das Gegenteil zu.
Ich kann ganz wunderbar auf e10s verzichten (andere offenbar auch, siehe Guido*), nicht aber auf z.B. Mausgesten, vertikale Tabs etc.
*Wenn man erst unter about:support nachsehen muß und es sonst gar nicht bemerkt, kann der Mehrwert nicht sehr groß sein.
Mir ging es in einem Test hier auch so… Außer mehr RAM Verbrauch (und ebenso mehr CPU Benutzung!) habe ich nichts festgestellt bei der Benutzung.
Dass die Mehrheit der Firefox-Nutzer kein einziges Add-on nutzt, ist allerdings eine Tatsache. Das heißt nicht, dass Add-ons für Firefox nicht wichtig wären, aber auch mit all den bevorstehenden Änderungen bleibt Firefox ja immer noch der am besten anpassbare (bedeutsame) Browser. Und man muss halt auch einfach sehen, dass das bisherige Modell (erlaube Änderungen von außen jeder Art und vollkommen ohne Kompromisse) ein Modell ist, welches Firefox nicht nur gut getan hat. Klar ist es schön, wenn man viel machen kann. Aber im Vergleich zu Chrome hindert das die Weiterentwicklung von Firefox auf bedeutsame Art, geht auf Kosten der Stabilität von Firefox und es sorgt für ständige Inkompatibilitäten von Erweiterungen, ist für Erweiterungs-Entwickler also auch nicht unbedingt nur rosarot, wie es früher war.
Nur weil du etwas nicht bewusst wahrnimmst, kann es also keinen großen Mehrwert besitzen? Eine sehr eigenartige Aussage.
Nicht grundlos ist im Artikel permanent ausdrücklich von einer Architektur die Rede. Das ist kein für den Nutzer greifbares Feature. Faktoren wie Performance, Stabilität und vor allem Sicherheit sind für ausnahmslos jeden Nutzer relevant, auch wenn man diese nicht bewusst wahrnimmt.
Mozilla führt ja auch nicht ohne Grund den größten Umbau von Firefox durch, den Firefox in seiner gesamten Geschichte je erlebt hat. Man sollte wirklich nicht glauben, dass das passiert, obwohl sich daraus überhaupt kein Mehrwert ergibt.
Dann sei doch froh! Das ist das beste, was passieren kann, wenn alles gewohnt gut funktioniert und keine sichtbaren Regressionen entstehen. Gerade der Tabwechsel ist noch eine kritische Sache. Und wenn das bei dir ohne sichtbare Änderung funktioniert, funktioniert e10s bei dir bereits ausgesprochen gut. Ein höherer RAM-Verbrauch ist erwartungsgemäß, das geht anders gar nicht bei einer Multiprozess-Architektur, aber RAM ist ja auch dafür da, genutzt zu werden.
@Sören:
Asche über mein Haupt… jo, ich geb dir da Recht. 🙂
Das alte SDK ist in meinen Augen gar nicht mal der zentrale Punkt. Es geht einfach um den Status Quo. Ich hatte letztens einen Artikel bei Ghacks mitbekommen, wo wieder die "Selbstzerstörung" von Mozilla wegen der WebExtensions angesprochen wurde. Der Artikel selber ist natürlich Blödsinn, aber wenn man so durch die Kommentare scrollte, war die Kernaussage wirklich die, dass XUL fallen soll. Genau da hat Pale Moon eben seinen Vorteil, wenn mans denn so nennen will. Vonnem Massenexodus will ich zwar nicht sprechen, aber ich traue den werten Leuten da drüben schon zu, den einen oder anderen Entwickler abzugraben.
@blub:
Chromium ist in dem Fall nicht entscheidend. Momentan gibt es in der Fraktion einen Trend, die Leute mit großen "Innovationen" im Bereich Sicherheit und Privatsphäre zu ködern. Yandex bietet eine umfassende Verschlüsselung an, Maxthon kommt bei MX5 mit u.a. nem Passwortmanager daher und Opera hat jetzt Features wie BrowserVPN oder Adblock mit an Bord. Gerade bei Opera, wo Qihoo einen Teil der Kontrolle ausübt, finde ich schon, dass das halbwegs wie eine Honigfalle wirkt, die sich irgendwann als Retourkutsche entpuppen wird.
Was Vivaldi anbelangt, zieht der einen nicht unwesentlichen Teil seiner Nutzer tatsächlich von Firefox ab. Viele Leute hatten Firefox getestet, nachdem der alte Opera 12 zunehmend unbenutzbar wurde. Außerdem wird Vivaldi langsam beliebter. Wird interessant zu sehen sein, wo der Browser in einem Jahr ist, wenn auch der Mailclient etc. integriert wurden.
Mozilla hat in dem Punkt aber auch selber gepennt und einige falsche Entscheidungen getroffen. Das sage nicht nur ich, sondern auch Leute wie Mark Mayo (siehe http://www.theverge.com/2017/1/25/14376710/walt-mossberg-mozilla-firefox-browser-revived ) und Jen Simmons (?), die sich da in Selbstkritik üben. Gecko ist zwar keine schlechte, aber eben auch die mit Abstand älteste Rendering-Engine am Markt. Gleichzeitig kommt ein Projekt wie Electrolysis, auch wenn ich die Hintergründe verstehe und das kein Pappenstil ist mit dem Umbau, einfach um Jahre zu spät.
Mozilla hat ja das Portfolio, um Firefox grundlegend zu modernisieren. Rust, Quantum, e10s, die WebExtensions etc. zeigen das ja. Wichtig ist mir nur, dass Firefox auch relativ zügig jetzt in den Genuss davon kommt, damit er wieder einigermaßen zu alter Stärke zurückfinden kann.
hat es einen grund warum bei der aktuellen version 32-bit steht, wird das dann wieder auf 64-bit raufgesetzt, mit dem nächsten update??
Gruß dm
Also ich sehe das komplett anders. Was soll das für eine tolle Innovation sein, wenn der User gar nichts davon bemerkt? Es wird ja bei e10s gerne von (deutlich) besserer Performance geredet, nur merke ich subjektiv nichts davon. Sorry, aber eine handvoll % zügiger bringt mir nix.
Ich sehe einfach, daß länger je mehr Addon Devs das Handtuch schmeißen.
– Ich sehe nicht mal mehr eine e10s kompatible Mausgesten Addon, geschweige denn daß sich hier was bewegt Richtung WebExtensions (geht das überhaupt?)
– Quicksaver hat das Handtuch geworfen, von ihm alleine hatte ich 3 Addons hier.
– DownthemAll wird nicht mehr gehen, wie es scheint. Und etwas in der Art muss man ja haben, denn der Firefox eigene Download "Manager" verdient den Namen gar nicht erst.
– Auch Aris (Classic Theme Restorer) hat offensichtlich langsam genug.
Klar tauchen eventuell neue Entwickler auf irgendwann, aber alleine schon diese Ungewißheit ist nervig.
Was weiß ich. Jedenfalls arbeiten da ja ganz viele Leute, und die müssen ja irgendwie beschäftigt sein…
Ist ja auch nicht so, daß jede Weiterentwicklung Sinn macht, außer für die Hersteller. Sieht man doch in vielen Bereichen, wozu muß ein Gelegenheitsknipser eine 20 MP Kamera haben? Wer braucht 4K Fernseher, wo doch erwiesenermaßen ein normalsichtiger (aus üblicher Distanz) *nicht* unterscheiden kann ob ein Hull HD oder ein 4K Film läuft? Irre Internet Geschwindigkeiten, 500mbit+ für Homeuser, die wenigsten werden das ausnützen.
Elektrische Büchsenöffner und Pfeffermühlen, Duschbrausen mit 20 verschiedenen Einstellungen, vollkommen nutzloser Mist in meinen Augen. Und so weiter.
Sicher, aber nur, wenn es sinnvoll genutzt wird, 😉
@Antares:
Ergänzend, weil es mir gerade einfällt: Embedding ist wieder ein Thema bei Mozilla, wenn auch erst einmal nicht vom Desktop ausgehend. Aber Mozilla arbeitet an GeckoView, um Gecko Android-Entwicklern zur Verfügung zu stellen.
Eben, wenn es um den Status Quo geht, wird es problematisch mit Pale Moon. Der der Status Quo ist, dass Pale Moon eine schlechtere und keine bessere Add-on-Unterstützung anbietet als Firefox. Und das wird mit dem Erscheinen von Firefox 57 kein bisschen besser. Dann unterstützt Firefox zwar keine XUL- und keine SDK-Erweiterungen, Pale Moon aber keine SDK- und keine WebExtension-Erweiterungen. Die Situation dann ist, dass beide Browser komplett eigene Add-on-Ökosysteme haben. Aber ich kenne keinen Entwickler, der seine Zeit verschwendet, um nur Pale Moon zu bedienen. Das heißt, so ziemlich alle tollen neuen Erweiterungen wird es nur für Firefox geben und nicht für Pale Moon. WebExtensions werden mit der Zeit ja auch immer mehr können, Stand heute ist nicht Stand 2018 oder gar 2019.
Man kann genauso argumentieren, dass XUL-Erweiterungen selbstzerstörerisch für Firefox sind und auch wenn ich persönlich weder in das eine noch in das andere Extrem gehen würde, wäre ich eher dabei, dass XUL-Erweiterungen schaden als dass es WebExtensions tun. Denn XUL-Erweiterungen können eine Menge und das ist ohne Frage toll. Aber Mozilla zahlt dafür einen enorm hohen Preis, der es unmöglich macht, Firefox in einem ähnlichen Tempo weiterzuentwickeln, wie Google das mit Chrome kann. Und am Ende beschweren sich die Nutzer, wenn Chrome besser ist. Es geht halt nicht alles.
XUL ist halt nur kein wirklicher Vorteil, sondern einer der größten Schwachpunkte, die Firefox besitzt.
Ich würde nicht sagen, dass Gecko die mit Abstand älteste Engine ist. Denn die grundlegende Architektur aller aktuellen Browser-Engines (gut, die von Edge vielleicht ausgenommen, da bin ich mir nicht sicher) stammen alle aus der gleichen Zeit, inklusive Blink. Die Engines haben alle seit damals nur permanente inkrementelle Verbesserungen erhalten. Man sieht es am Servo-Projekt, wie viele Jahre es dauert, eine wirklich moderne Engine von null zu entwickeln. Das hat sich bisher nicht einmal Google zugetraut (mit der Anmerkung im Kleingedruckten, dass sie theoretisch natürlich im Geheimen daran werkeln könnten).
Das ist eine Sache von Prioritäten. Es ist ja bekannt, mit was für einem Aufwand e10s verbunden ist. Als e10s erstmals ein Thema war, gab es deutlich wichtigere Baustellen in Firefox und Mozilla konnte wesentlich mehr spürbaren Effekt mit wesentlich weniger Aufwand erzielen. Darum war es damals auch sinnvoll, dass Mozilla den ersten Anlauf für e10s beendet hatte.
Nun ist e10s seit sehr langer Zeit wieder ein Thema und benötigt sehr viel Zeit. Man sollte sich aber auch mal die Frage stellen, wieso das so viel Zeit benötigt. Gibt es irgendetwas, was sich hier extrem verzögernd auswirkt? Eine Antwort darauf sind Add-ons. Als Google die Multiprozess-Architektur eingeführt hat, gab es kein solches Erweiterungssystem, wie Firefox es anbietet. Google hatte nicht nur die Erfahrungen, was bei Firefox gut und schlecht lief, es gab auch viel weniger Dinge, auf die sie Rücksicht nehmen mussten. Und nicht zuletzt ist es natürlich auch eine Ressourcen-Frage. Dass Google sehr viele Entwickler mehr hat, ist ja auch klar.
@dm:
Das steht da, wenn du eine 32-Bit-Version von Firefox nutzt. Automatisch wird da nichts raufgesetzt. Du musst dir schon die 64-Bit-Version installieren, wenn du Firefox als 64-Bit-Version nutzen möchtest. 😉
Den Download findest du hier:
https://www.mozilla.org/en-US/firefox/all/#de
Beachte die "64" im Symbol bei der Wahl der Version.
@Tom:
Wer spricht von Innovation? e10s ist eine Architektur-Verbesserung, innovativ ist daran überhaupt nichts. Eine Multiprozess-Architektur hatte bereits der Internet Explorer noch vor Chrome, so ein alter Hut ist das.
Und wie bitte möchtest du bewusst wahrnehmen, dass dein Firefox stabiler läuft oder du weniger anfällig für Sicherheitsprobleme bist? Würdest du das deutlich wahrnehmen, würde bei deinem Firefox etwas gewaltig schief laufen. Das heißt nicht, dass es die Verbesserungen nicht gibt und dass du davon nicht profitieren würdest.
Ich weiß natürlich nicht, auf welchen Seiten du noch liest, aber wenn du Berichterstattung zu Mozilla-bezogenen Themen von jemandem möchtest, der weiß, wovon er in Bezug auf Firefox spricht, das kann ich anbieten. Und was mich betrifft, war in diesem Zusammenhang noch nie von "deutlich besserer Performance" die Rede. Im Idealfall kann sich das positiv auf die Performance auswirken, aber grundsätzlich gehen Daten ja erst einmal längere Wege und müssen zwischen Prozessen kommunizieren, Performance ist also eine große Herausforderung. In erster Linie ist e10s eine Notwendigkeit, um Sicherheit und Stabilität besser gewährleisten zu können.
Entwickler kommen und gehen, das war schon immer so, daran ist überhaupt nichts neu. Ich bin selbst Erweiterungsentwickler und finde WebExtensions toll. Ich habe bereits eine veröffentlicht und meine nächste Erweiterung, die noch viel größer ist als meine letzte WebExtension, hätte ich als SDK-basierte Erweiterung nicht entwickelt. Und als XUL-Erweiterung schon gar nicht, davon bin ich bereits vor mehreren Jahren abgekehrt.
Keine Ahnung, da ich keine Maus besitze.
Wie gesagt, Entwickler kommen und können, das gab es schon immer. Vor Jahren haben schon Entwickler das Handtuch geworfen und neue sind immer wieder gekommen.
Ob es konkret DownThemAll gibt oder nicht, ist vollkommen irrelevant, denn Erweiterungen wie DownThemAll sind definitiv weiterhin möglich. Und von welchem Entwickler und welchem Namen sowas kommt, spielt keine wirkliche Rolle. Zumindest für mich spielt es keine.
Aris hat nun einmal das Problem, dass er Erweiterungen entwickelt, die in besonderem Maße gegen die Ziele der WebExtensions gehen, weswegen er einen Großteil seiner Wünsche nicht erfüllt bekommen kann. Das ist wirklich Pech, aber so schlecht wie ihm geht es vielen anderen Entwicklern nicht, da die meisten Erweiterungen mehr funktionaler Natur sind und weniger darauf ausgelegt sind, jede Ecke der Benutzeroberfläche zu verändern.
War es die letzten 15 Jahre nervig?
Ich hoffe, dass du das als Scherz meinst und nicht ernsthaft als Option siehst, dass Firefox nur zum Spaß einem massiven Umbau unterzogen wird.
Ich nehme mal an, dass du keinen 4K-Fernseher besitzt und daher nicht weißt, wovon du redest. Denn ich besitze einen 4K-Fernseher und der Unterschied zu HD ist sogar sehr deutlich sichtbar. Es ist natürlich logisch, dass man einen 4K-Fernseher mit entsprechendem Material füttern muss, um den Vorteil zu sehen. Ein HD-Bild bleibt nun einmal ein HD-Bild. Aber wer einen 4K-Fernseher besitzt, so wie ich, schaut sich ja auch weniger DVDs an als viel mehr Blu Rays oder gar Ultra HD Blu Rays.
Und ja, ich finde es schön, wenn meine Dusche mehr als eine Brauseneinstellung besitzt. Du solltest vielleicht nicht alles abwerten, was du selbst nicht nutzt. Es ist nur deswegen nicht automatisch schlecht.
Blink, was ja die unterliegende Engine von allen Chromium-basierten Browsern (also z. B. auch Opera) ist, ist selber nur ein Fork von WebKit, welche eine der allerältesten Browser-Engines überhaupt ist (und übrigens z. B. von Safari verwendet wird).
Bei Edge sieht es ähnlich aus. EdgeHTML (so heißt die Engine von Edge) ist ein Fork von Trident, welches die Engine vom Internet Explorer war (bzw. ist), wobei viele Altlasten (ActiveX, Browser Helper Objects, …) rausgeflogen sind. Trident wurde mit dem ersten IE eingeführt, ist dementsprechend auch schon ganz gut alt.
Alle heute verwendeten Browser-Engine sind alt oder sind zumindest Forks von den ursprünglichen Engines. Außerdem würde ich nicht sagen, dass Code, nur weil er "alt" ist, zugleich unbedingt schlecht sein muss. Er kann allerdings, wie man bei Edge beim Übergang von Trident zu EdgeHTML gesehen hat, noch Support für heute nicht mehr verwendete Technologien enthalten, das ist aber bei Firefox so nicht der Fall. Firefox hatte nie Unterstützung für Technologien wie ActiveX, und durch ständige inkrementelle Veränderungen ist ein so massiver Schnitt wie der Fork von Trident auf EdgeHTML nicht nötig.
Dagegen halte ich den Ansatz von Project Quantum sehr sinnvoll, langsam aber sicher wichtige Teile von Gecko durch in Rust geschriebenen Code zu ersetzen, mit den Vorteilen Sicherheit, Performance und Multi-threaded execution.
Ich denke, wenn wir Firefox uns in einem Jahr anschauen, wird daraus ein Browser geworden sein, der bei der Entwicklung (endlich) wieder an vordersten Front dabei ist.
Aufteilung in mehrere Content-Prozesse (und andere Prozesse wie den GPU-Prozess), Sandboxing und dann die Ergebnisse von Project Quantum sind ein extrem wichtiger Schritt für Firefox. Dazu werden erst das Einstellen von NPAPI-Plugins ab FF52, dann das von XUL- und SDK-basierten Add-ons ab FF57, wirklich große Schritte für Performance und Sicherheit nach sich ziehen.
Ich glaube nur, dass der Übergangsprozess, der sich wohl über ganz 2017 ziehen wird, sehr schmerzhaft sein wird. Insofern kann man natürlich überlegen, die Unterstützung von XUL-/SDK-Add-ons erst mit der nächsten ESR-Version (FF59?) zu entfernen, sodass (ähnlich wie jetzt mit FF52 & den NPAPI-Plugins) der Übergang für alle, die das noch unbedingt brauchen, etwas geglättet wird.
Auf jeden Fall freue ich mich auf Firefox in 2018!
In der Story von Daniel fehlte noch das Webkit ein Fork von KHTML ist, aus dem KDE Desktop Projekt, irgendwo um 1997/1998 rum sind die Wurzeln. Trident hat dagegen Wurzeln in NCSA Mosaic, die sich glaube ich auch lange erhalten haben…
Anyways: Ich glaube auch dass der Umschwung schmerzhaft wird, ich hänge aber wenig an XUL, hab kein Problem mit Australis und hänge auch wenig an anderen Altleichen. Das neue war immer mal wieder etwas anders, aber alles andere als Showstopper. Ich glaube auch wenn man XUL und Freunde später beerdigt, würde das nur für eine Verlängerung der schmerzhaften Phase sorgen, das wäre nicht in meinem Interesser. Von daher: Vollgas voran.
Können Addons mit dem neuen Addon-System (Webextensions) und Multiprozess (e10s) eigentlich noch auf Passwortfelder zugreifen und somit diese Funktionalität erweitern?
Klar. Passwortfelder sind normale Elemente einer Webseite und mit Webseiten kann auch mit e10s und WebExtensions interagiert werden.
Speziell, was die Interaktion mit dem DOM einer Webseite betrifft, sind Anpassungen für e10s zwingend notwendig, verglichen damit, wie man früher Add-ons entwickelt hat. Aber bereits mit SDK-basierten Erweiterungen ist man in der Regel auf der sicheren Seite, was das betrifft. Mit WebExtensions sowieso.
Für a11y musste ich die Suchmaschine meiner Wahl bemühen. Die Abkürzung kannte ich bisher noch nicht.
Ich habe einen 4K PC Monitor. Und glaub mir, ich habe da -zig Tests gemacht mit Filmen, denselben Film in 1920p und 4K, mittels ALT-TAB hin- und her geswitcht und selbst im Standbild (!) so gut wie keine Unterschiede festgestellt.
Und nein, das waren keine lausig encodierten Youtube Filmchen, sondern da waren solche dabei mit 20mbit/s
Wesentlich interessanter wären 50 oder 60 FPS, da ist die Industrie aber wenig interessiert, da man hierfür keine neue Hardware benötigt…
Aber Gratulation, daß Du zu den ganz wenigen gehörst, die einen deutlichen Unterschied erkennen.
Nein, aber seit das mit dem elenden "Rapid Release" Mist angefangen hat. Ich benutze schon länger Hauptsächlich die ESR Version, denn diesen Zirkus mit den Erweiterungen brauche ich nicht alle paar Wochen.
Du kannst gerne glauben, dass ich damit nicht "zu den ganz wenigen gehöre", es ist sogar ziemlich normal, dass man den Unterschied bemerkt, der Unterschied existiert schließlich. Es mag ja sein, dass du das nicht so wahrnimmst. Es soll sogar Leute geben, die kein 3D-Fernsehen wahrnehmen können (kein Witz) und der Unterschied ist deutlicher. Aber daraus zu folgern, dass in der Minderheit wäre, wer den Unterschied sieht, ist gewagt.
Mit solch unsachlichen Bemerkungen bewegt man sich auf eine Ebene, wo Kommentare Gefahr laufen, als Troll-Beiträge abgestempelt zu werden. Achte bitte auf deine Formulierungen. Ich sage das nur dieses eine Mal. Auf diesem Blog wird auch von den Kommentatoren ein gewisses Niveau erwartet. Das unterscheidet diesen Blog, abgesehen von der Artikel-Qualität, von den Mainstream-Medien.
Um auf den inhaltlichen Aspekt dieser Aussage einzugehen: Für die Produktentwicklung von Firefox war es eine sehr gute und sinnvolle Entscheidung, daran besteht für mich nicht der geringste Zweifel. Für Inkompatibilitäten von Erweiterungen kann Mozilla wenig. Und hinter der Annahme, dass die Situation mit nur einem Release pro Jahr tatsächlich anders wäre, steckt für mich auch wenig Logik. Denn die Uhren drehen sich mit einem anderen Release-Modell ja nicht langsamer. Es ist die exakt gleiche Menge an Anpassungen notwendig. Das alte Release Modell macht es für Erweiterungs-Entwickler aber sehr viel schwieriger Schritt zu halten, weil Änderungen eines Jahres mit einem Mal aufzuarbeiten, nun einmal sehr viel schwieriger ist als dies Schritt für Schritt mit einer überschaubaren Menge an Änderungen zu machen. Und du kannst mir glauben, dass ich weiß, wovon ich rede, denn ich bin Erweiterungs-Entwickler. Ich war das bereits zu Firefox 2-Zeiten, ich habe XUL-Erweiterungen geschrieben, ich habe SDK-basierte Erweiterungen geschrieben und jetzt bin ich Entwickler mehrerer WebExtensions. Wenn es dir wirklich um Erweiterungs-Kompatibilität geht, dann müsstest du WebExtensions sehr freudig erwarten. Klar gibt es erst einmal einen Bruch, aber ohne Bruch lässt sich dieser Aspekt logischerweise nicht verbessern, denn das Problem liegt halt in der Natur der Legacy Add-ons.
Ich habe im Artikel noch einen Abschnitt ergänzt, den ich ursprünglich vergessen hatte:
Ebenfalls ergänzt: Ziel für die Auslieferung von WebExtensions in einem eigenen Prozess: Firefox 55.
Zum Thema Sicherheit: Wären hier nicht auch die zusätzlichen Einstellungen, wie sie durch user.js (https://github.com/pyllyukko/user.js) vorgenommen werden, sinnvoll? Mit ein paar Einstellungen kann hier Firefox effektiv "hardened" werden. Wie seht ihr das?
Ich kann von dieser Liste nur abraten. Natürlich kann man Firefox "sicherer" machen, indem man einfach alles deaktiviert, inklusive zahlreicher wichtiger Webstandards (welch Ironie, bei einem Browser die Unterstützung für wichtige Webstandards zu deaktivieren), aber das kann nicht zielführend sein. Nicht nur, dass mit diesen Einstellungen viele Webseiten nicht mehr vollständig funktionieren, auch wenn sie noch funktionieren, bringt dies teilweise ziemlich überflüssige Probleme. Durch die Deaktivierung von WebGL beispielsweise muss Google Maps auf eine Fallback-Version ohne WebGL zurückgreifen, welche wesentlich langsamer ist.
Und den Absturzmelder von Firefox zu deaktivieren, das ist richtig dumm. Absturzberichte sind extrem wichtig und garantiert nur zum Vorteil von jedem Nutzer und nicht zum Nachteil von irgendjemandem. Außer man findet's toll, wenn Firefox öfter als nötig abstürzt, nur weil Mozilla nichts mehr von den Abstürzen weiß und entsprechend nichts mehr beheben kann.
Lange Rede, kurzer Sinn: besser Finger weg von diesem Käse. 😉
Ist das weiterhin der Plan? Oder wurde der Accessibility-Support auf Firefox 56 verschoben?
Eine weitere Verschiebung ist durchaus im Bereich des Möglichen, ich bin mir aber gerade nicht sicher und könnte das erst ab Dienstag überprüfen, da ich momentan im Urlaub bin. 😉