Fragen und Kommentar zum Kommentar: Wieso Firefox 57 Mozillas bester Release aller Zeiten wird

  • Zunächst mein Kompliment: Ein sehr guter zusammenfassender Artikel, der ziemlich umfangreich ist. Es bringt den Leser meiner Meinung nach gut auf einen aktuellen Stand. Auch wenn ich deine Meinung nur beschränkt teile, da ich zu den offenbar wenigen Nutzern mit ziemlich vielen Erweiterungen gehöre und von so einigen schon weiß, dass Sie vom ursprünglichen Autor nicht auf WebExtension migriert werden werden.

    Mir persönlich bleiben zum aktuellen Stand nach der Lektüre ein paar Fragen offen:

    - Wird es mit Photon weiterhin die Möglichkeit geben, ein Firefox 3-artikes Design zu erreichen (Menüband, Lesezeichenleiste...)?
    Auf HD+ Bildschirmen finde ich es einfach unnötig, jeden Pixel für die eigentliche Website nutzen zu wollen. Dies besonders dann, wenn man viel mit Lesezeichen und vielen Tabs arbeitet.

    - Wirkt sich Multiprozess nicht negativ auf den Speicherhunger aus?
    Vor gut einem jahr sah das noch nicht rosig aus, habe da aber nichts aktuelleres zu gefunden
    http://www.erahm.org/2016/02/11/mem…h-e10s-enabled/

    - Was wird mit WebExtensions ganz klar nicht erlaubt? Insbesondere: welche API-Anfragen wurden von Mozilla abgelehnt?
    (Du bist ein bisschen auf Oberflächengestaltung eingegangen, aber nicht auf "echte" Funktionalität)

    - Welche Vorteile haben Firefox-WebExtensions konkret gegenüber Chrome/Opera?
    Du nennst hier die Sidebar, was noch?

    - Wenn es um Performance und Ballast geht: Wäre es nicht sinnvoll, Webentwickler-Tools auszugliedern, sodass sie nur bei denen mitgeladen werden, die sie auch nutzen?

  • Zunächst mein Kompliment: Ein sehr guter zusammenfassender Artikel, der ziemlich umfangreich ist. Es bringt den Leser meiner Meinung nach gut auf einen aktuellen Stand.

    Danke. Und ja, umfangreich ist der Artikel. 3.551 Wörter, um genau zu sein. ;)

    Wird es mit Photon weiterhin die Möglichkeit geben, ein Firefox 3-artikes Design zu erreichen (Menüband, Lesezeichenleiste...)?

    Mir sind keine Pläne bekannt, die Menüleiste zu entfernen, daher gehe ich fest davon aus, dass es die weiterhin optional geben wird. Die Lesezeichen-Leiste wird es definitiv weiterhin geben.

    Wirkt sich Multiprozess nicht negativ auf den Speicherhunger aus?
    Vor gut einem jahr sah das noch nicht rosig aus, habe da aber nichts aktuelleres zu gefunden
    http://www.erahm.org/2016/02/11/mem…h-e10s-enabled/

    Von Eric Rahm gibt es einen neuen Teil zu diesem Thema, der Artikel ist vom März, also relativ aktuell:
    http://www.erahm.org/2017/03/10/are-they-slim-yet-round-2/

    Und ja, eine Multiprozess-Architektur wirkt sich zwangsläufig auf den Speicherverbrauch aus. Aber das ist ein Mehrverbrauch, der gewollt ist. Natürlich will man nicht, dass der Browser plötzlich das Zehnfache an Speicher braucht. Aber eine Multiprozess-Architektur hat sehr große Vorteile und das hat nun einmal einen Preis. Die allgemeine derzeitige Tendenz ist, dass, solange man bei unter acht Content-Prozessen bleibt, auch weiterhin einen geringeren RAM-Bedarf hat als Google Chrome. Natürlich kann das im Einzelfall anders aussehen. Aber Firefox bekommt eh eine sichtbare Einstellung zur Konfiguration der Content-Prozesse (bereits in Firefox 55).

    Was wird mit WebExtensions ganz klar nicht erlaubt? Insbesondere: welche API-Anfragen wurden von Mozilla abgelehnt?
    (Du bist ein bisschen auf Oberflächengestaltung eingegangen, aber nicht auf "echte" Funktionalität)

    Es gibt nicht wirklich eine Liste, was nicht möglich ist. Da Erweiterungen bisher alles beliebig verändern konnten, weil es keine echten Schnittstellen gab, welche genutzt werden mussten, wäre die Liste der Dinge, die möglich waren, nahezu unendlich.

    Wie du schon erwähnst, die Veränderung der Oberfläche ist nicht mehr beliebig möglich. Und alles, was du über about:config umstellen kannst, ist nicht mehr beliebig per Erweiterung veränderbar. Einzelne Einstellungen werden über spezielle APIs zugänglich gemacht, aber es gibt keine Schnittstelle mehr, um gezielt Schalter aus about:config zu verändern. Ansonsten, ich führe auch keine Liste darüber, welche API-Vorschläge Mozilla ablehnt. Die Sache ist nun einmal, dass an WebExtension-APIs gewisse Versprechen geknüpft sind. Beispielsweise zur Kompatibilität mit Firefox-Updates. Und das kann nur erreicht werden, wenn man sich ganz genau überlegt, was man erlaubt und was nicht.

    Welche Vorteile haben Firefox-WebExtensions konkret gegenüber Chrome/Opera?
    Du nennst hier die Sidebar, was noch?

    Zunächst einmal würde ich Opera weniger mit Chrome in einem Atemzug nennen als mit Firefox und auch Microsoft Edge. Wieso? Zum einen, weil auch Microsoft Edge mittlerweile eine darauf basierende Erweiterungs-Schnittstelle anbietet, zum anderen weil Mozilla, Microsoft und Opera ein gemeinsames Interesse haben, einige der Erweiterungs-Schnittstellen standardisieren zu lassen, so dass diese wirklich browserübergreifend funktionieren. Google ist hier überhaupt nicht beteiligt, die interessiert das nicht, was die anderen Browserhersteller machen.

    Zum anderen ist wichtig, dass unterschiedliche Browser nun einmal unterschiedliche Browser sind. Kein Browser ist darauf beschränkt, was andere Browser machen. Beispielsweise hat Firefox auch eine WebExtension-API für Container-Tabs, ein Feature, welches in anderen Browsern überhaupt nicht existiert. Mozilla implementiert aber auch nicht alles, was andere Browser haben. Ein Beispiel dafür ist eine API zur Verwaltung von Add-ons. Sowas hat Chrome, Mozilla hat aber kein Interesse, das zu implementieren, weil Mozilla die Ansicht vertritt, dass der Add-on Manager ausreichend ist.

    Die Frage lässt sich final nicht beantworten, weil jederzeit neue APIs dazu kommen können, in jedem Browser.

    Wenn es um Performance und Ballast geht: Wäre es nicht sinnvoll, Webentwickler-Tools auszugliedern, sodass sie nur bei denen mitgeladen werden, die sie auch nutzen?

    Aus Performance-Sicht bringt das keinen nennenswerten Vorteil. Wenn du die Entwicklerwerkzeuge nicht nutzt, machen sich diese eh nicht negativ bemerkbar.

    Aber die Entwicklerwerkzeuge werden sowieso bereits in Firefox 56 als Add-on ausgelagert werden. Nicht wegen der Performance. Sondern viel mehr, um unabhängig von Firefox aktualisiert werden zu können.

    Wo du aber Performance im Zusammenhang mit den Entwicklerwerkzeugen ansprichst, die Entwicklerwerkzeuge haben Performance-Probleme. Wenn man sie benutzt. Denn diese machen intern sehr starken Gebrauch vom Add-on SDK und das Add-on SDK hat sehr starke Performance-Defizite. Auch daran, dass die Entwicklerwerkzeuge das SDK nicht mehr benutzen, arbeitet Mozilla derzeit.


  • Von Eric Rahm gibt es einen neuen Teil zu diesem Thema, der Artikel ist vom März, also relativ aktuell:
    http://www.erahm.org/2017/03/10/are-they-slim-yet-round-2/

    Aber eine Multiprozess-Architektur hat sehr große Vorteile und das hat nun einmal einen Preis.


    Danke für den Link. Sieht ja wirklich recht gut aus. Ich frage mich noch, wie die Aufteilung eigentlich erfolgt. Wie bestimmt sich, welche Tabs in welchem CP laufen? - Man sollte ja vermeiden, dass meineBank.de und illegalStreams.com im selben CP landen.
    Und: Mit 4 CP würde das nicht bedeuten, dass im Zweifel 1/4 der Tabs mit abstürzen, wenn einer crasht?
    Sicher, das ist besser als alle - es sollte aber dann auch möglich sein, diese gezielt wiederherzustellen (an vorheriger Stelle). Für viele Nutzer wäre das sicherlich auch schwer verständlich?!....


    Es gibt nicht wirklich eine Liste, was nicht möglich ist. Da Erweiterungen bisher alles beliebig verändern konnten, weil es keine echten Schnittstellen gab, welche genutzt werden mussten, wäre die Liste der Dinge, die möglich waren, nahezu unendlich.

    [...]Ansonsten, ich führe auch keine Liste darüber, welche API-Vorschläge Mozilla ablehnt. Die Sache ist nun einmal, dass an WebExtension-APIs gewisse Versprechen geknüpft sind. Beispielsweise zur Kompatibilität mit Firefox-Updates. Und das kann nur erreicht werden, wenn man sich ganz genau überlegt, was man erlaubt und was nicht.


    Der erste Teil war mehr als einleitende Motivation gedacht, nicht als eigenständige Frage. Sorry.
    Ich hatte erwartet, dass es eine derartige Liste von MDN o.ä. gibt. - Damit nicht 50 verschiedene Entwickler die gleiche Schnittstelle anfragen, die es eh nicht geben wird.


    Google ist hier überhaupt nicht beteiligt, die interessiert das nicht, was die anderen Browserhersteller machen.


    Naja, da Opera als Blink-Browser zwangsläufig Chrome nacheifert und sich Edge als Nachzügler verständlicher Weise eher am Weltmarktführer Chrome orientiert als am Firefox, der im Umbruch steht, ist das wenig verwunderlich.


    Zum anderen ist wichtig, dass unterschiedliche Browser nun einmal unterschiedliche Browser sind. Kein Browser ist darauf beschränkt, was andere Browser machen. Beispielsweise hat Firefox auch eine WebExtension-API für Container-Tabs, ein Feature, welches in anderen Browsern überhaupt nicht existiert. Mozilla implementiert aber auch nicht alles, was andere Browser haben. Ein Beispiel dafür ist eine API zur Verwaltung von Add-ons. Sowas hat Chrome, Mozilla hat aber kein Interesse, das zu implementieren, weil Mozilla die Ansicht vertritt, dass der Add-on Manager ausreichend ist.


    Interessant. Daraus lerne ich zum Beispiel, das "Slim add-on Manager" auch rausfliegen wird.


    Die Frage lässt sich final nicht beantworten, weil jederzeit neue APIs dazu kommen können, in jedem Browser.


    Natürlich nicht, aber zum aktuellen Stand. Was haben die WebExtensions mit Containern zu tun?

  • Danke für den Link. Sieht ja wirklich recht gut aus. Ich frage mich noch, wie die Aufteilung eigentlich erfolgt. Wie bestimmt sich, welche Tabs in welchem CP laufen? - Man sollte ja vermeiden, dass meineBank.de und illegalStreams.com im selben CP landen.

    Ich weiß nicht, ob das wirklich eine notwendige Anforderung ist. Ansonsten müsste jede Webseite in einem eigenen Prozess laufen und das ist vorerst nicht umsetzbar, weil der Ressourcen-Verbrauch zu hoch wäre. Ich würde hier mehr auf andere Sicherheitsmechanismen des Browsers vertrauen, dass eine kompromittierte Webseite nicht an Inhalte aus anderen Tabs im gleichen Content-Prozess zugreifen kann. Ich kenne mich da aber auch nicht detailliert aus, wie genau das Sicherheits-Modell ist.

    Die Auswahl des Content-Prozesses erfolgt bis einschließlich Firefox 53 komplett zufällig. In Firefox 54 wurde eine einfache Logik implementiert, welche immer den Prozess auswählt, der gerade die wenigsten Tabs beinhaltet. Das ist noch keine perfekte Lösung, wurde aber implementiert, weil es vergleichsweise einfach war und auf jeden Fall besser als purer Zufall ist.

    Und: Mit 4 CP würde das nicht bedeuten, dass im Zweifel 1/4 der Tabs mit abstürzen, wenn einer crasht?
    Sicher, das ist besser als alle - es sollte aber dann auch möglich sein, diese gezielt wiederherzustellen (an vorheriger Stelle). Für viele Nutzer wäre das sicherlich auch schwer verständlich?!....

    Korrekt, im Zweifel stürzt dann ein Viertel der Tabs ab. Ich weiß nicht, ob das wirklich schwer verständlich für die Nutzer ist. Ich meine, vorher wäre der komplette Browser abgestürzt. Nun bleibt der Browser offen und eine Seite erscheint, um die Tabs wiederherzustellen. Es werden per Klick alle Tabs des Prozesses wiederhergestellt, das muss also nicht für jeden Tab einzeln gemacht werden.

    Ich hatte erwartet, dass es eine derartige Liste von MDN o.ä. gibt. - Damit nicht 50 verschiedene Entwickler die gleiche Schnittstelle anfragen, die es eh nicht geben wird.

    Wenn es denn überhaupt so viele Entwickler geben würde, die sich die Mühe machen, Mozilla um die Implementierung einer API zu bitten, das ist doch eher überschaubar… ;) Natürlich ist ein gewisses Grundset an APIs ja auch schon vorhanden, womit sich ein Großteil benötigter Funktionalität umsetzen lässt. Aber alle zwei Wochen gibt es ein Meeting, bei dem vorgeschlagene APIs diskutiert werden, daran kann sich jeder beteiligen. Neben-Information: in dieser Woche wurden zwei Vorschläge von mir diskutiert. Eines davon wird umgesetzt und das andere vermutlich eingeschränkt und nicht so komplex, wie ich es gerne gehabt hätte.

    Dass da die gleichen Dinge angefragt werden, kommt auf jeden Fall gar nicht so häufig vor. Im Endeffekt sind die Entscheidungen ja öffentlich und man kann suchen, bevor man etwas vorschlägt.

    Naja, da Opera als Blink-Browser zwangsläufig Chrome nacheifert und sich Edge als Nachzügler verständlicher Weise eher am Weltmarktführer Chrome orientiert als am Firefox, der im Umbruch steht, ist das wenig verwunderlich.

    Naja, aber ein gemeinsames Interesse haben wie gesagt eher Mozilla, Microsoft und Opera. Und die Sidebar-API, die ich erwähnte, die wird nicht von Chrome unterstützt, aber neben Firefox auch von Opera. De facto hat sich Mozilla hier an Opera orientiert. ;)

    Natürlich nicht, aber zum aktuellen Stand. Was haben die WebExtensions mit Containern zu tun?

    Die Container sind ein Feature, welches nur Firefox besitzt. Firefox besitzt eine WebExtension-API dafür, so dass Erweiterungen interessante Dinge damit anstellen können. Da andere Browser keine Container besitzen, ist das ein Beispiel für eine WebExtension-API, welche es nur in Firefox gibt.

  • Hab so meine Zweifel das was besser wird mit dem FF wird immer unstabiler und immer mehr von den Addons die man gern
    hatte und auf die man nicht verzichten will funktionieren nicht mehr.Letzter Streich von Mozilla ist das mein Lazarus Addon
    unter 53.xx.xx nicht mehr funktiort.Echt klasse Mozilla


  • Hab so meine Zweifel das was besser wird mit dem FF wird immer unstabiler und immer mehr von den Addons die man gern
    hatte und auf die man nicht verzichten will funktionieren nicht mehr.Letzter Streich von Mozilla ist das mein Lazarus Addon
    unter 53.xx.xx nicht mehr funktiort.Echt klasse Mozilla

    Du bist komplett am Thema vorbei. Wenn du Probleme mit Firefox hast, eröffne einen eigenen Thread. Darum geht es hier kein bisschen. Oder habe ich deine Fragen zum Artikel übersehen?

    Aber grundsätzlich instabiler wird Firefox auf gar keinen Fall. Das widerlegen die Metriken sogar ganz eindeutig:
    https://health.graphics/crashes

    Wie man sieht, ist Firefox so stabil wie schon ganz lange nicht mehr.

    Instabilitäten haben aber immer einen Grund. Wie gesagt, eröffne ein eigenes Thema, verlinke dort deine letzten Absturzberichte von about:crashes. Dann kann man sich das ansehen. Das wäre ein sinnvolles Vorgehen statt nur Mimimi und Schuldzuweisung an Mozilla, dass ein Add-on von seinem Entwickler nicht mehr fortgesetzt wird (wie kann man überhaupt auf die Idee kommen, dass das Mozillas Schuld wäre, wenn ein Add-on seit Jahren kein Update erhält?).