Entwicklung Firefox

Das ist es in dem Fall nicht, die Updates kommen weiterhin automatisch, lassen sich aber nicht manuell anstoßen.

Und wie lange gibt es das Problem schon? Mir käme https://bugzilla.mozilla.org/show_bug.cgi?id=1458308 in den Sinn, was Updates auf Windows betrifft. Vielleicht gab es da ja eine Regression (ist nur geraten, aber das einzige, was mir an aktuellen Änderungen einfällt, was mit Updates zu tun hat). Die Patches wären vor fünf Tagen gelandet, also lass uns sagen, weil es seit dem ja wenigstens ein Update gegeben haben muss, seit vier Tagen. Kommt das hin oder ist das Problem erst später aufgetreten?

Hier ein bereits offenes Ticket zu dem Problem:
https://bugzilla.mozilla.org/show_bug.cgi?id=1506371

Demnach liege ich mit meinem Verdacht richtig, was die Regression ausgelöst hat.

Zitat von Lurtz

Ist die Updatesuche über "About Nightly" in den Windows-Builds bei euch auch kaputt? Meldet immer up to date, selbst wenn es einen neuen Build gibt...

Problem ist seit gerade eben behoben, das heißt, der Fix wird im nächsten Nightly sein und wenn die übernächste Version erscheint, sollte diese auch wieder über den Info-Dialog installiert werden können.

[attachment=0]firefox_2018-11-14_22-23-00.png[/attachment]
Mir ist heute aufgefallen das manuelle Update taucht hier nicht mehr auf.
Bleibt das so oder ändert sich da noch etwas?

Zitat von Abendstern2010

das manuelle Update

Ich vermute mal eine falsche Übersetzung des unteren Eintrages. Denn auf deinem Screenshot ist der Haken ja schon bei automatisch, ergo müsste es unten dann heißen: manuel :-??

Stimmt doch alles.

Wenn "Add-ons automatisch aktualisieren" aktiviert ist, heißt der letzte Eintrag "Alle Add-ons umstellen auf automatische Aktualisierung" und wenn "Add-ons automatisch aktualisieren" nicht aktiviert ist, heißt der letzte Eintrag "Alle Add-ons umstellen auf manuelle Aktualisierung". Die Funktion ist in beiden Fällen die Gleiche: Die entsprechende Einstellung für alle Add-ons wird auf "Standard" zurückgestellt. Da könnte auch einfach immer stehen "Alle Add-ons umstellen auf die Standard-Einstellung". Der Text reflektiert also ganz einfach, was der Standard ist.

Man kann die Update-Regel ja für jedes Add-on einzeln konfigurieren. Und ob man nun den Haken bei den automatischen Updates drin hat oder nicht, das zählt ja nur für alle Add-ons, die in ihrer Einzelkonfiguration nicht auf "Standard" stehen. Die Option am Ende des Menüs setzt das für alle Add-ons auf "Standard", so dass die Option darüber wieder für alle Add-ons gilt, falls man vorher etwas abweichend konfiguriert hat.

Auf Automatisch habe ich keins gestellt und in einem neuem frischen Profil sieht es genauso
aus.
[attachment=0]firefox_2018-11-14_22-45-40.png[/attachment]

Siehe meine letzte Antwort, passt doch alles. Und in Firefox 64 sieht es ganz genauso aus.

Sören sry nach 3 maligen lesen hat es klick gemacht :oops:

Die neuen Datenschutz-Einstellungen für Firefox 65 sind nun implementiert.

Zitat von Sören Hentzschel

22 entfernte XBL-Bindings nur am Donnerstag, das war mal ein effektiver Tag. Insgesamt sind es jetzt nur noch 113 von ursprünglich 300, die es vor knapp über einem Jahr noch gab.

Neuer XBL-Status knapp einen Monat nach diesem Zwischenstand: Nun sind nur noch 94 XBL-Bindings von ursprünglich 300 in Firefox übrig. Von den In-Content-Bindings gibt es seit gestern überhaupt keine mehr. Damit braucht es gar keine XBL-Unterstützung im Content-Prozess mehr, was sich positiv auf den RAM-Verbrauch von Firefox auswirkt.

[attachment=0]Screenshot 2018-01-19 10.31.30.png[/attachment]
Das Bild zeigt den RAM-Verbrauch für 10.000 span-Elemente, links mit XBL im Content-Prozess, rechts ohne XBL im Content-Prozess: 3,4 MB im Gegensatz zu vorher 6,2 MB.

[attachment=1]Bildschirmfoto 2018-11-23 um 09.34.21.png[/attachment]

Da stand ganz grosser Käse.
Auf jeden Fall eine grossartige Leistung, ich freue mich schon auf den letzten Bug der alle grossen Abhängigkeiten rauslöscht (wenn es ihn dann geben wird).

Zitat von miku23

Da stand ganz grosser Käse.

Und nur weil ich zu langsam war, werde ich nun nie erfahren, was du geschrieben hast? Dabei hatte ich doch extra mit dem Lesen gewartet, weil ich in der Online-Liste gesehen hatte, dass der Beitrag editiert wird.

Hier noch etwas über was ich eher zufällig gestolpert bin, als ich unter der aktuellsten Nightly eine benutzerdefinierte Suchmaschine von der Seite mycroftproject.com oder auch von der AMO-Seite installieren wollte:

Unter Firefox 65 Nightly hat Mozilla die WebAPI Window.external zum testen auf mögliche Regressionen deaktiviert, da diese WebAPI nach aktuellem Webstandard überholt bzw. deprecated wäre, und möglicherweise schon ab Firefox 66 gänzlich entfernt werden soll. ►siehe auch Bug 1503551 oder diesen ghacks-Artikel für weitere Infos.

Die besagte WebAPI beinhaltete Funktionen wie AddSearchProvider(), mit welcher man externe Suchplugins auf Seiten wie AMO oder auch mycroftproject.com installieren konnte, wie auch selbst erstellte benutzerdefinierte Suchen mittels Erweiterungen wie ContextSearch web-ext oder Add custom search engine. (siehe auch Screenshot)
[attachment=0]firefox_2018-11-23_12-26-11.png[/attachment]

Da die Funktion unter Nightly deaktiviert ist, funktioniert das oben beschriebene hinzufügen von Suchmaschinen nicht mehr, wobei die Funktion momentan noch mittels des about:config Schalters dom.sidebar.enabled reaktiviert werden kann.

Meine Meinung dazu: Mit dem vorab-testen der deaktivierten WebAPI unter Nightly habe ich persönlich kein Problem, sehe aber die Idee, diese Funktion schon für Firefox 66 zu deaktivieren als ein wenig überhastet an, vor allem wenn es für diese Funktion noch keine funktionierende Alternative gibt (Bug 1504338), und die Entfernung auch die Installation der Suchplugins auf der eigenen Addonseite (=AMO) verunmöglicht

Überhastet wird da nichts, weil bei Mozilla solche Zeitpunkte nie in Stein gemeiselt sind. Wenn von Firefox 66 die Rede ist, dann schwingt darin automatisch mit: unter der Voraussetzung, dass alles, was dafür notwendig ist, umgesetzt ist. Wenn nicht alles passt, wird daraus Firefox 67 oder später. Solche Szenarien gab es schon zahlreich in der Vergangenheit und Mozilla ist alles andere als zimperlich damit, Dinge zu verschieben, wenn keine zwingende Notwendigkeit besteht, etwas in einem bestimmten Zeitpunkt zu erreichen.

Wobei es sowieso noch zwei Monate Zeit sind, bis Firefox 66 die Betaphase erreicht, also eine ganze Menge Zeit, um viel zu schaffen. Gut, natürlich muss man auch einiges abziehen wegen der Weihnachts- und Neujahrs-Urlaube, dann ist es effektiv weniger Zeit. Aber das wird sich dann eh zeigen, ob noch mehr Zeit benötigt wird.

Zum Thema Suchmaschinenen; soweit ich es verstehe wird aktuell die einzige Möglichkeit sein eine Suchmaschine hinzuzufügen über die Addressbar (oder Awesomebar oder wie die auch immer inzwischen heisst^^).
Ich kann die Deaktivierung auch gut verstehen, die Funktion wird meiner persönlichen Einschätzung nach nur von einem geringen Anteil der User (weniger als 5 Prozent) wirklich aktiv und gewollt genutzt. Wenn eine legacy API genutzt wird, wird diese halt schneller deaktiviert/entfernt als wenn es eine weit verbreitete Funktion betrifft.

Zitat von Sören Hentzschel

Und nur weil ich zu langsam war, werde ich nun nie erfahren, was du geschrieben hast? Dabei hatte ich doch extra mit dem Lesen gewartet, weil ich in der Online-Liste gesehen hatte, dass der Beitrag editiert wird.

Sorry

Ich hatte mich darüber gewundert wieso der Content-Prozess XBL-Frei sein sollte wenn doch der dazugehörige meta bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1443836) noch nicht abgeschlossen ist. Ich merkte dann eine Minute später, dass die verbleibenden Sachen nur noch nicht mehr genutzten Code darstellen der noch entfernt werden muss.

Okay.

Zitat von miku23

die Funktion wird meiner persönlichen Einschätzung nach nur von einem geringen Anteil der User (weniger als 5 Prozent) wirklich aktiv und gewollt genutzt.

Ich kenne keine Nutzungszahlen dazu, aber mit fünf Prozent wäre das Feature sogar ziemlich gut genutzt. Es gibt prominentere Features, die noch weniger genutzt werden. Daher würde ich von einer sehr viel geringeren Zahl ausgehen.

Ausschlaggebend dürfte in diesem Fall wirklich sein, dass die API nicht mehr Teil der Webplattform ist, das heißt, aus dem Standard gestrichen worden ist. Oder besser gesagt: Der Standard definiert explizit, dass die Methode AddSearchProvider() nichts machen darf. Und für Mozilla ist wichtig, was der Standard sagt. Wenn das viele genutzt hätten, vielleicht wäre das ja wichtiger als der Standard gewesen. Aber wenn der Standard das sagt und die Nutzung gering ist, war das vermutlich keine schwierige Entscheidung.

Gute Nachrichten übrigens zu den Reflow-Problemen, die Firefox in vielen Webapps wie WhatsApp Web geplagt haben: Die sind in Firefox 65 praktisch behoben, in vielen Fällen produziert Firefox jetzt weniger (teure) Reflows als Chrome.

Die Probleme auf WhatsApp waren für mich zwar nie nachvollziehbar, da überhaupt nicht spürbar, aber da ich durch das entsprechenden Bugzilla-Ticket weiß, dass es für manche andere spürbar war, ist das in jeden Fall eine wichtige Performance-Verbesserung.

---

Der in Firefox seit Version 64 integrierte "Task-Manager" zeigt neben dem Energie-Verbrauch von Tabs und Erweiterungen nun auch den Speicherverbrauch an.