Und ab Firefox 93 wird es für den Benutzer nicht länger möglich sein, WebRender abzuschalten. Großer Meilenstein, denn ab jetzt können alte Code-Pfade entfernt werden. 🎉
Wird dieser "Meilenstein" auch Thunderbird betreffen? Warum ist es wichtiger, dass der Quellcode hübscher wird als dass der Text lesbar bleibt und nicht unscharf wird?
Ich war gerade nach dem Thunderbird Update auf v91 froh, dass es noch die Möglichkeit gibt, WebRender zu deaktivieren.
Was hat das bitte damit zu tun, dass der "Quellcode hübscher" wird? Darum geht es mal sicher nicht. 
Und selbstverständlich bedeutet WebRender nicht, dass der Text unscharf und unlesbar werden soll. Optisch sollte der Nutzer überhaupt keinen Unterschied bemerken. Wenn du mit aktiviertem WebRender ein Problem hast, von dem offensichtlich kaum sonst jemand betroffen ist, wird es höchste Zeit, dass du Mozilla dieses Problem meldest!
Ich weiß nicht, wieso immer wieder Leute glauben, dass etwas abzuschalten, von dem eigentlich klar ist, dass das nicht für immer so funktionieren kann, ein Problem lösen würde. 
Probleme lösen sich nur, wenn man etwas gegen die Probleme tut, und das Mindeste, was man als Anwender tun kann, ist überhaupt mal zu sagen, dass man ein Problem hat. Bei Mozilla arbeiten schließlich keine Hellseher. Vom Ignorieren verschwinden Probleme nicht und wenn WebRender dann nicht mehr abschaltbar ist und man nicht aktiv wurde, obwohl man das Problem zuvor schon Monate lang hatte, braucht man sich hinterher auch nicht zu beklagen.
Thunderbird nutzt die gleiche Plattform, ja. Aber wenn du bei Thunderbird 91 bereits WebRender deaktivieren musstest, hast du die Frage ja eigentlich schon selbst beantwortet.
91 und 91esr sind immer kleiner als 93 
Dass mit dem schlankeren bzw. bereinigtem Code halte ich schon für wichtig. Du hast mal Telemetrie für allerlei Entscheidungen bei Mozilla begründet, verstehen nur die wenigsten - und meistens diejenigen, eine Minderheit würde ich behaupten, die mit solchen Entscheidungen sehr hadern. Aktuell gehört der Schalter für das Abschalten der "Kürzlich als Lesezeichen gesetzt" Anzeige. CSS ist willkommen aber für viele ist selbst das bisschen schon zuviel. *** Mozilla, so ungefähr.
Wird dieser "Meilenstein" auch Thunderbird betreffen? Warum ist es wichtiger, dass der Quellcode hübscher wird als dass der Text lesbar bleibt und nicht unscharf wird?
Ich war gerade nach dem Thunderbird Update auf v91 froh, dass es noch die Möglichkeit gibt, WebRender zu deaktivieren.
Ja und es gibt dazu bereits für beide Biotope einen Vermerk
Weil da "blob-images" genannt wurde, das ist es:
Nachtrag - hat jemand dieses Problem?
(hier ist derzeit alles stabil mit der build vom 11.8., musmüsste das Update laden.)
Bei mir in der Nightly läuft gerade folgendes Experiment:
Fission Process Count
Track the stability and performance effects of increasing the number of Fission content processes.
Was genau ändert das? Ist bei Fission die Anzahl der Content-Prozesse nicht grundsätzlich unbegrenzt? Oder geht es dabei um die "preallocated" Content-Prozesse?
Je nachdem, ob du in der Test- oder Kontrollgruppe bist, wird dom.ipc.processCount.webIsolated auf 1 oder 4 gesetzt, sprich maximal ein oder bis zu vier Content-Prozesse pro Seite.
Ah, dafür gibt es auch noch eine Metrik. Und die isoliert dann Tabs bzw. Frames einer Domain voneinander (Wert >1) oder nicht (Wert=1)?
Ich möchte noch was zum WebRender-Thema ergänzen, weil ich es beim letzten Mal vergessen hatte zu erwähnen: Wenn Hardware-WebRender Probleme macht, kann ja immer noch Software-WebRender aktiviert werden. Die Wahrscheinlichkeit, dass man damit genau das gleiche Problem hat, dürfte verschwindend gering sein. Dass man WebRender ab Firefox 93 (und damit ab Thunderbird WelcheVersionAuchImmerImJahr2022) nicht mehr abschalten können wird, heißt ja nicht, dass man gezwungen ist, die Hardware zu nutzen. Es gibt nach wie vor ein Software-Backend, welches für manche Konfigurationen sogar dauerhaft Standard bleiben wird. Software-WebRender ist keine temporäre Geschichte, sondern ein Fallback für die Konfigurationen, die mit Hardware-WebRender auf Grund veralteter Hardware oder Treiber respektive Treiber-Bugs nicht funktionieren und möglicherweise auch nie funktionieren werden.
Monatliches Fission-Update!
Ich habe vor, jetzt immer zum jeweils nächsten Monat ein Fission-Update zu geben (immer im Vergleich zum letzten Monat):
M8 (1% der Release-Nutzer): 0 (-30)
MVP (Standardmäßige Aktivierung in finaler Version): noch 33 offene Tickets (+2)
In meiner Nightly-Installation ist gerade ein Experiment für Tab Unloading aktiv. Wird das später mal im UI konfigurierbar sein, wie zB beim Microsoft Edge, oder sind das erstmal nur frühe Experimente?
Ist das auch was für die Androidversion oder funktioniert die Speicherverwaltung da gänzlich anders?
In meiner Nightly-Installation ist gerade ein Experiment für Tab Unloading aktiv. Wird das später mal im UI konfigurierbar sein, wie zB beim Microsoft Edge, oder sind das erstmal nur frühe Experimente?
Mir sind keine Pläne für eine sichtbare Einstellung dafür bekannt, das ein- und ausschaltbar zu machen. Das steht in Zusammenhang mit Fission und soll inaktive Tabs entladen, wenn der RAM knapp wird. Das ist also ein Feature, welches für den Nutzer möglichst transparent funktionieren sollte und nicht wirklich sinnvoll zu deaktivieren wäre, weil Firefox dann schlicht und ergreifend häufiger abstürzen würde. Falls du mit UI eine Oberfläche wie chrome://discards in Chrome meinst, dafür ist bereits was in Arbeit, aber erst einmal nur, um den Status nachvollziehen zu können, also ohne weitere Features wie beispielsweise bestimmte Tabs grundsätzlich vom automatischen Entladen auszuschließen.
Das Feature ist übrigens nicht neu. Das wurde bereits in Firefox 67 ausgeliefert und dann aus der Ferne wieder für alle Nutzer deaktiviert, weil die Logik für die Erkennung von RAM-Knappheit fehlerhaft war. Jetzt ist das praktisch eine verbesserte Form. Sogar der Name des Schalters in about:config ist noch der gleiche wie vor zwei Jahren.
Für ausgefallenere Anwendungsfälle und Optionen gibt es Add-ons wie dieses hier:
Ist das auch was für die Androidversion oder funktioniert die Speicherverwaltung da gänzlich anders?
Du kannst davon ausgehen, dass die Speicherverwaltung anders funktioniert, die unterscheidet sich nämlich selbst zwischen Windows, macOS und Linux. Wie RAM verwaltet wird, ist immer sehr spezifisch für jedes Betriebssystem. Das aktive Experiment für Firefox 93 ist daher auch nur für Windows, für macOS und Linux ist noch Arbeit zu erledigen.
Firefox für Android hat auch eine Logik, um auf RAM-Knappheit zu reagieren. Erstens haben Smartphones häufig deutlich weniger RAM, zweitens ist Android selbst recht aggressiv, was das eigenständige Beenden von Prozessen betrifft. Insofern ist da natürlich besonders wichtig, dass RAM an den richtigen Stellen freigegeben wird, wenn Firefox merkt, dass der RAM knapp wird. Ich habe jetzt nur nicht die Details im Kopf, was genau auf Android passiert.
Ok, danke für den Kontext. Ich vermute Tabs, mit denen der User interagiert hat, werden entsprechend priorisiert, und beim erneuten Anklicken kann der Inhalt inklusive eingegebener Inhalte schnell wiederhergestellt werden?
Nutzt das Addon die gleiche "API" wie die interne Funktion?
Ich fragte nur nach Android weil es da ja ein großes Problem zu sein scheint, wenn der "RAM Saver" von Android dann hart Prozesse abschießt. Deshalb haben die Chromium-Browser ja weniger isolierte Tabs als unter Desktop-Betriebssystemen und auch bei Firefox liest man immer wieder, dass damit gekämpft wird, dass teilweise Prozesse ungewollt abgeschossen werden.
Ich habe zB beim Öffnen neuer Tabs immer mal das Problem, dass sie im about:blank Status festhängen bis zum Neustart der Anwendung, ich vermute das könnte ähnliche Ursachen haben.
Ich vermute Tabs, mit denen der User interagiert hat, werden entsprechend priorisiert
Korrekt, diese Tabs werden nicht einfach entladen. Das ist der aktuell implementierte Algorithmus, nach welchem entschieden wird, welche Tabs entladen werden:
The algorithm used is:
- Sort all of the tabs by a base weight. Tabs with a higher weight, such as
those that are pinned or playing audio, will appear at the end. When two
tabs have the same weight, sort by the order in which they were last.
recently accessed Tabs that have a weight of NEVER_DISCARD are included in
the list, but will not be discarded.- Exclude the last X tabs, where X is the value returned by getMinTabCount().
These tabs are considered to have been recently accessed and are not further
reweighted. This also saves time when there are less than X tabs open.- Calculate the amount of processes that are used only by each tab, as the
resources used by these proceses can be freed up if the tab is closed. Sort
the tabs by the number of unique processes used and add a reweighting factor
based on this.- Futher reweight based on an approximation of the amount of memory that each
tab uses.- Combine these weights to produce a final tab discard order, and discard the
first tab. If this fails, then discard the next tab in the list until no more
non-discardable tabs are found.
Was Punkt 1 betrifft, sind neben gepinnten Tabs und welchen, die Sound abspielen, Tabs, die gerade laden, PiP-Modus oder WebRTC weitere Optionen, die jeweils ein unterschiedliches Gewicht haben. Das X in Punkt 2 sind zehn Tabs.
und beim erneuten Anklicken kann der Inhalt inklusive eingegebener Inhalte schnell wiederhergestellt werden?
Korrekt.
Nutzt das Addon die gleiche "API" wie die interne Funktion?
Es gibt eine Erweiterungs-Schnittstelle zum "Entladen" von Tabs, die von dieser Erweiterung genutzt wird und das gleiche macht wie der Mechanismus von Firefox. Nur besteht das Feature von Firefox darin, das anhand des beschriebenen Algorithmus automatisch zu machen, sobald der RAM ausgeht, während die Erweiterung den RAM-Verbrauch nicht messen kann und dementsprechend eine andere Logik implementiert, wann und welche Tabs automatisch zu entladen sind (oder manuell per Knopfdruck).
Ich fragte nur nach Android weil es da ja ein großes Problem zu sein scheint, wenn der "RAM Saver" von Android dann hart Prozesse abschießt. Deshalb haben die Chromium-Browser ja weniger isolierte Tabs als unter Desktop-Betriebssystemen
Klar, am Smartphone muss man sparsamer mit den Prozessen umgehen, da jeder zusätzliche Prozess einen RAM-Overhead bedeutet und Smartphones häufig eher wenig RAM haben. Ein durchschnittliches Mittelklasse-Smartphone wie das Moto G5 beispielsweise hat 2 GB RAM, was am Desktop ja schon fast undenkbar wenig ist.
bei Firefox liest man immer wieder, dass damit gekämpft wird, dass teilweise Prozesse ungewollt abgeschossen werden.
Ich habe zB beim Öffnen neuer Tabs immer mal das Problem, dass sie im about:blank Status festhängen bis zum Neustart der Anwendung, ich vermute das könnte ähnliche Ursachen haben.
Ich habe das Problem nicht, aber mit 12 GB RAM liegt mein Smartphone ja auch weit über dem Durchschnitt eines Smartphones. Ich weiß nicht, wie viel RAM dein Smartphone hat, vielleicht ist es eh nicht wenig, aber einen Zusammenhang vermute ich schon insofern, als dass ich davon ausgehe, dass viel RAM eine geringere Wahrscheinlichkeit für dieses Problem bedeutet. Ansonsten könnte es aber auch sein, dass die Content-Prozesse aus anderen Gründen als RAM-Knappheit bei dir abstürzen.
Falls du mit UI eine Oberfläche wie chrome://discards in Chrome meinst, dafür ist bereits was in Arbeit, aber erst einmal nur, um den Status nachvollziehen zu können, also ohne weitere Features wie beispielsweise bestimmte Tabs grundsätzlich vom automatischen Entladen auszuschließen.
about:unloads ist nun in der Nightly-Version von Firefox enthalten.
In der Nightly von heute kann ich die Bibliothek nicht mehr maximieren, der Button (nur der eine von den Dreien) reagiert nicht. Der von Firefox schon. Wenn ich nach dem CSS suche, finde ich es für den browser, aber nicht für die Bibliothek, weg, nicht da.
Ist im Zuge von Fission geplant jede aktive WebExtension in einen eigenen Prozess zu packen, so wie es Chromium seit kurzem tut?
Sollte das irgendwann passieren, dann eher unabhängig von Fission, denn bei Fission geht es ja um die Website-Isolierung. Zumindest aktuell weiß ich nichts von solchen Plänen.
Chromium hab ich das schnell abgewöhnt, diesen Mumpitz. 40+ Prozesse, ich glaub es hakt. Wahrscheinlich für die Masse uninteressant...
Firefox ist doch längst auch auf dem Weg dahin.
