E10s in der Nightly

Mozilla interessiert sich nicht für Tickets zu TMP, welche einfach nur TMP betreffen, diese Tickets haben nichts in Mozillas Bugtracker zu suchen. Aber wenn es um Probleme geht, die in Zusammenhang mit einer großen Änderung innerhalb von Firefox stehen, wie es bei Australis der Fall war und jetzt bei e10s, das interessiert Mozilla, das lesen die Mozilla-Entwickler. Dafür gibt es einen eigenen Metabug für Kompatibilitätsprobleme zwischen e10s und Add-ons, mit welchem entsprechende Tickets verknüpft werden sollten:

https://bugzilla.mozilla.org/show_bug.cgi?id=905436

Adblock Plus unter e10s hat sogar einen ganz eigenen Metabug mit mehreren Tickets als Abhängigkeit.

Danke!

Muß ich heute mal sagen, so wenig Probleme wie mit der heutigen e10s habe ich bisher noch nicht gehabt.

Einzig die Remove it Permanently Erweiterung funktioniert nicht. Kann man aber weitgehehend mit ABP ausgleichen. RIP ist eigentlich nur für besonders harte Fälle interessant wo man ABP nicht einsetzen kann wegen Adblocker checks.

Schön zu lesen, dass die allgemeine Tendenz bzgl. e10s positiv zu sein scheint, vor allem in Anbetracht der Tatsache, dass e10s ab Version 40 standardmäßig nicht mehr nur in der Nightly Version, sondern auch in der Developer Edition aktiviert sein wird.

Um den Fortschritt mal darzustellen, ich notiere mir jeden Donnerstag Abend wenige Minuten nach Mitternacht (also genau genommen schon Freitag) die Anzahl der Blocker jedes Meilensteins. Bis einschließlich Meilenstein 6 sind die Tickets, welche geschlossen werden müssen, damit e10s in der Developer Edition aktiviert werden kann. Hier mal der Verlauf der letzten zehn Wochen:

143 (-5)
135 (-8)
123 (-12)
118 (-5)
108 (-10)
98 (-10)
93 (-5)
66 (-27)
59 (-7)
35 (-24)

Aktuell sind es noch 33 offene Tickets bis zum grünen Licht. Der sogenannte Aurora-Merge findet am 11. Mai statt, also noch etwas Zeit.

Die Anzahl der Betablocker (Meilensteine 7 und 8 ) ist dafür ähnlich extrem getiegen wie die Anzahl der Aurora-Blocker gesunken ist (von 69 auf 198 in der gleichen Zeit, derzeit 196), aber die Bugs, die in den hinteren Meilensteinen dazukommen, sind natürlich nicht so gravierend wie die Bugs, die in den früheren Meilensteinen behoben werden müssen. Und wenn der sechste Meilenstein erst einmal komplettiert ist, dürftend die Betablocker in einem ähnlichen Tempo runtergehen wie die Aurorablocker.

Wohl etwas zu früh gefreut: "Enable E10S (multi-process) (disabled: An accessibility tool is or was active. See bug 1115956.)"
So richtig versteh ich nicht worum es da geht, aber das wird sich dann die nächsten Tage klären.

Mozillas a11y-Bibliothek unterstützt noch kein e10s, daher wird e10s automatisch deaktiviert, wenn ein entsprechendes Werkzeug verwendet wird. Halt solange, bis a11y+e10s funktioniert.

Mozilla hat sich nun dafür entschieden, noch einen Zyklus mit der standardmäßigen Aktivierung von e10s in der Developer Edition zu warten, sprich Version 41. Wobei Nutzern der Version 40 wohl eine Opt-In-Option angezeigt werden wird. Für die Beta ist weiterhin Version 41 geplant, oder 42, das wird man sehen.

Mir fällt auf GitHub nichts auf. Ich hab mich jetzt einfach ein bisschen durchgeklickt. Getestet unter Windows 10 Build 10130 und mit ABP als einziges Add-on. Ich würde an deiner Stelle mal ohne Add-ons testen, ob das etwas verändert.

In der Developer Edition Edition 41 wird e10s auch noch nicht standardmäßig aktiviert werden:
https://wiki.mozilla.org/index.php?titl…t&oldid=1079694

Das liegt daran, dass Firefox bislang nur einen einzigen Content-Prozess gemeinsam für alle Tabs nutzt. Das kann man über about:config ändern, was auch die Performance etwas verbessern dürfte, aber man sollte das dennoch nicht tun, denn wenn Mozilla erstmals Firefox mit e10s ausliefern wird, dann zunächst nur mit einem Content-Prozess, die offizielle Unterstützung für mehr als einen Content-Prozess ist erst danach ein Thema. Denn naheliegenderweise muss Firefox erstmal mit einem Prozess gut klarkommen, bevor Firefox mit mehreren Prozessen gut klarkommt, und Mozilla konzentriert sich bislang ausschließlich auf die Konfiguration mit einem Content-Prozess, alles andere ist nicht unterstützte Konfiguration. Und wenn man das über about:config ändert und Telemetrie auch noch aktiviert ist, wird's für Mozilla schwieriger, weil die Ergebnisse dann vermischt werden, die Mozilla dabei helfen sollen, zu erkennen, wo die Probleme liegen, mit den Absturzberichten sieht's vielleicht ähnlich aus.

Tritt das Problem denn auch ohne das Add-on auf?