Entwicklung Firefox

    Wie gesagt, auf meinen relativ schnellen Rechnern bemerke ich es meist bei WhatsApp Web. Das tritt nicht immer auf, aber je nachdem welche Reflows gerade ausgelöst werden, kann es extrem langsam werden, so dass man weit unter 30 fps liegt. Das ist dann schon sehr störend wahrnehmbar. Zwar nicht unbenutzbar, aber weit entfernt von "Chrome-Parity".
    In anderen Tickets wird bswp. von deutlicher Buchstabenverzögerung beim Tippen im Nachrichtenfenster bei Twitter geschrieben. Das hatte ich noch nie, da sind meine Rechner dann wahrscheinlich doch zu schnell.

    Man kann es auch auf die Spitze treiben und Firefox damit komplett abschießen, ist die Frage wie wichtig solche Edge Cases letztlich sind:
    https://bugzilla.mozilla.org/show_bug.cgi?id=1448672
    Eine "normale" Website würde sowas wahrscheinlich nicht tun.

    Dann sind meine Arbeitsgeräte wohl auch zu schnell, denn ich habe auf keinem meiner Macs ein wahrnehmbares Problem bei WhatsApp. ;)

    Solche Fälle wie der, um den es in dem nun verlinkten Ticket geht, sind natürlich extrem und glücklicherweise absolute Ausnahmen. Da kommen wohl sowohl eine schlechte Umsetzung der Seite als auch Schwächen von Firefox zusammen. Eine Behebung des einen Problems könnte in dem Fall das andere Problem vermutlich super kaschieren, sprich eine besser umgesetzte Seite würde Firefox nicht alt aussehen lassen (ich vertrete die Meinung, dass es immer auf ein Webseiten-Problem hindeutet, wenn eine Seite einen Browser derart in die Knie zwingt, das muss nicht sein!) und umgekehrt, wenn der Browser damit besser umgeht (wie Chrome), fällt nicht auf, dass die Seite schlecht umgesetzt ist. So ist das natürlich die schlechteste Kombination.

    So wie ich das sehe, geht es in dem Fall um Performance-Probleme mit der Flexbox-Implementierung von Firefox. Das Thema wird definitiv Beachtung finden, alleine schon im Rahmen der De-XUL-ifizierung von Firefox, weil man dafür eine performante Flexbox braucht. Anders gesagt, um auf deine Frage bezüglich Pläne zu antworten: ich bin mir ziemlich sicher, dass es geplant ist, hier Verbesserungen zu erreichen. Einen Zeitplan kenne ich nicht.

    Retained Display Lists wurden auf Firefox 61 verschoben und das find ich gut so. Ich sehe nach wie vor Probleme damit in Firefox Nightly.

    Die Unterstützung für Telemetrie-Experimente wurde aus Firefox entfernt. Für Experimente hat man ja mittlerweile die SHIELD-Studien.

    Was die Entfernung von XBL aus Firefox betrifft (https://bgrins.github.io/xbl-analysis/) hat man nun bereits über ein Drittel (101 von 300) geschafft.

    Das dunkle Theme von Firefox ist ja seit ein paar Tagen an vielen anderen Stellen wie Menü und neuem Tab nun auch dunkel. Das hat in den letzten Tagen weiteren Feinschlimm erhalten und sieht nun wesentlich besser aus (nicht mehr dieses extrem dunkle Schwarz, das war nicht schön).

    Die macOS-Version von Firefox besitzt nun eine Integration in das native Sharing vom Betriebssystem, siehe Screenshot.

    Stimmt danke, hab ich wohl in der Eile falsch gelesen. Wenigstens räumen sie ein wenig auf.
    Hab gerade deinen anderen Post gesehen, sorry dass ich die auf die falsche Fähre geführt habe :)

    Glückwunsch auch von mir, habe den RT vom offiziellen Account gesehen. Hast du auch Kenntnisse in Cocoa? Es gäbe da einige Sachen die unter macOS noch geändert werden sollten :) (Natürlich aus meiner Sicht^^)

    Stylo kann CSS nun parallel parsen, das hat erneut deutliche Geschwindigkeitsverbesserungen bewirkt:
    https://bugzilla.mozilla.org/show_bug.cgi?id=1455115#c3

    Firefox 60 und höher wird nun zu 100% mit Taskcluster gebaut:
    https://atlee.ca/blog/posts/migration-status-3.html

    Das Dark-Theme-Darkening-Projekt wird nächste Woche abgeschlossen:
    https://groups.google.com/forum/#!topic/…dev/F0R-mWTOvr4

    Zitat von Sören Hentzschel

    Solche Fälle wie der, um den es in dem nun verlinkten Ticket geht, sind natürlich extrem und glücklicherweise absolute Ausnahmen. Da kommen wohl sowohl eine schlechte Umsetzung der Seite als auch Schwächen von Firefox zusammen. Eine Behebung des einen Problems könnte in dem Fall das andere Problem vermutlich super kaschieren, sprich eine besser umgesetzte Seite würde Firefox nicht alt aussehen lassen (ich vertrete die Meinung, dass es immer auf ein Webseiten-Problem hindeutet, wenn eine Seite einen Browser derart in die Knie zwingt, das muss nicht sein!) und umgekehrt, wenn der Browser damit besser umgeht (wie Chrome), fällt nicht auf, dass die Seite schlecht umgesetzt ist. So ist das natürlich die schlechteste Kombination.

    So wie ich das sehe, geht es in dem Fall um Performance-Probleme mit der Flexbox-Implementierung von Firefox. Das Thema wird definitiv Beachtung finden, alleine schon im Rahmen der De-XUL-ifizierung von Firefox, weil man dafür eine performante Flexbox braucht. Anders gesagt, um auf deine Frage bezüglich Pläne zu antworten: ich bin mir ziemlich sicher, dass es geplant ist, hier Verbesserungen zu erreichen. Einen Zeitplan kenne ich nicht.


    Die Flexboxen werden jetzt gecacht, damit lädt die Seite nun sogar etwa doppelt so schnell wie in Chrome :D

    Einmal editiert, zuletzt von Lurtz (21. April 2018 um 20:05)

    Falls sich jemand wundert wieso man nichts mehr von Quantum DOM hört, das Projekt ist, jedenfalls in der ursprünglich geplanten Form, tot:
    https://bugzilla.mozilla.org/show_bug.cgi?id=1435689#c4

    Schade dass die aufgeworfenen Fragen in Comment 8 nicht beantwortet wurden:

    Zitat

    It's pretty unfortunate that we spent a lot of time getting this code into the tree + various kinds of support and then we're going to begin ripping it out shortly thereafter (and probably bits and pieces will still be coming out for the rest of this year, at least). Do we think the design is flawed, we didn't push hard enough on making it happen (perf measurements, flushing bugs, whatever), something else, or some combination of the above?


    Angesichts der Tatsache, dass Quantum DOM in einem öffentlichen Mozilla Hacks-Artikel vorgestellt wurde und immer noch im Wiki als wichtiger Teil von Quantum genannt wird, ist das schon erstaunlich.
    Ob das was mit der Abwesenheit von Bill McCloskey zu tun hat :-??

    Überhaupt scheint die Performancearbeit wieder etwas ins Stocken geraten zu sein.
    Speedometer 2.0 sitzt in der Nightly aktuell bei -36% Punkten verglichen mit Chrome Canary, ohne dass sich da noch groß was tut. Das Langziel war, schneller als Chrome zu werden. Da scheint man Momentum verloren zu haben, während man schon mal fast an Chrome dran war.
    QF scheint generell an Fokus verloren zu haben, wie ich zum Ende der Newsletter mit 57 schon befürchtet hatte. Es gibt immer noch ein paar Bugs mit bekanntem starken negativen Performanceauswirkungen, die seit Monaten offen sind.

    Das ist natürlich nur meine laienhafte Außenperspektive, ich behaupte nicht den Gesamtstand beurteilen zu können. Habe in der praktischen Erfahrung aber doch das Gefühl, dass es gerade im Bereich DOM noch große Verbesserungen im Vergleich zu Chromium möglich wären.

    Ich kann nicht wirklich bestätigen, dass die Arbeit an der Performance ins Stocken geraten sei, siehe beispielsweise die Flexbox-Performance-Steigerung, auf die du kürzlich erst hingewiesen hast und die wirklich signifikant ist, oder das parallele CSS-Parsing. Daneben stehen noch zahlreiche andere Performance-Projekte für 2018 auf der Roadmap. Performance ist definitiv noch ein großes Thema. Ich kann nichts Konkretes zu Quantum DOM sagen, weil ich dazu aktuell nichts gelesen habe, aber grundsätzlich besteht die Möglichkeit immer, dass bestimmte Dinge zurückgestellt werden, sich als nicht vorteilhaft genug oder schwieriger in der Umsetzung als gedacht heraustellen und dafür dann andere Dinge priorisiert werden, weil damit mehr positiver Effekt in kürzerer Zeit erzielt werden kann. Das ist nicht ungewöhnlich und auch im Falle von Firefox nicht das erste Mal, siehe erster Anlauf für e10s. ;)

    Was ich aus dem Ticket herauslese, ist, dass das, was in diesem Ticket entfernt wird, für Quantum DOM sowieso nicht genutzt worden wäre ("we're not going to use it for Quantum DOM") und dass der Code, welcher sehr viel Komplexität hinzufügt, sowieso nicht funktional ist ("it seems like choosing to hold off means keeping this non-trivial dead functionality around for at least a year or two). Weiterhin wurden mit "Given that we don't have any way to test the cooperative functionality in the browser and the shell testing machinery lacks expressiveness to really test it either and how easy it is to regress, this seems like a recipe for bitrot and mental overhead", weitere Punkte genannt, die unter diesen Voraussetzungen (nicht fuktionaler Code, an dem nicht mehr gearbeitet wird) wirklich nachvollziehbare Argumente für eine Entfernung sind, insbesondere da dieser Code andere Weiterentwicklungen blockierte ("I have some stuff on the JS side that's blocked on this, so I think I'll start landing patches…"). Insofern interpretiere ich da jetzt nichts Besonderes hinein. ;)

    In dem Link im Blink-Dev-Forum steht noch, dass die ersten gemessenen Performanceverbesserungen nicht gerade ermutigend waren. Da wird auch davon gesprochen dass der gesamte Ansatz des "cooperative scheduling" wahrscheinlich verworfen wurde ("We (Mozilla) are not in fact shipping cooperative scheduling so far, and it's unclear that we will be at all, given initial measurements"). Ist natürlich sinnvoller nicht der sunken cost fallacy zu erliegen, sondern dann tatsächlich einen Schlussstrich zu ziehen.

    Hätte nur gerne auch was Offizielles dazu gelesen, weil Quantum DOM eben im Vorfeld zu Firefox 57 oft als eine der Quantum-Komponenten genannt wurde. Auf der Servo 2018 Roadmap steht ja die Prüfung der möglichen Übernahme von DOM-Mechanismen aus Servo in Firefox. Vielleicht wird daraus ja etwas.

    Nochmal was amüsantes:
    Google bastelt hinter einer Flag gerade an einem Redesign von Chrome - mit runden Tabs, einem Plussymbol zum Öffnen neuer Tabs und anderen Firefox/Australis-Merkmale. Da Australis und Photon ja so oft vorgeworfen wurde, zum Chrome-Klon zu mutieren, zeigt das mal wieder deutlich wie bescheuert die ganze Debatte ums vermeintliche Kopieren von Browserdesigns eigentlich ist :D

    Mein Senf zum Amüsantem (und das ist es wirklich): Ich nutze zurzeit Chrome Canary als Browser im Alltag und habe mal heute Abend das Flag gesetzt nachdem ich gestern vom Redesign las. Meine Fresse, ich war ja schon kein Australis-Fan, aber die Implementaion toppt das mal um Längen. Nicht schön. Aber es ist nur hinter einem Flag und nur in der Canary-Version verfügbar, insofern sollte man das nicht voreilig kritisieren. Wer weiß schon, wie das am Ende wirklich aussehen wird.

    Und ja diese ganze Wer-kopiert-wen-Debatte war und ist in der Software-Welt schon immer müßig und irgendwie sinnlos, finde ich.

    Lurtz: Danke, dne Link hatte ich nicht gesehen / gelesen. Dann gibt es ja eine gute Begründung. Zwar nicht in Form eines Blog-Artikels oder dergleichen, aber mir reicht es, den Grund zu kennen. ;)

    ---

    Zum neuen Chrome-Design oder zumindest dem aktuellen Stand dessen: ich war auch noch nie ein Freund der Debatte, wer angeblich von wem kopiert. Vor allem: abgesehen davon, dass die Tabs rund sind, sehe ich nicht einmal viel Ähnlichkeit mit Australis, ähnlich wie damals schon Australis gar nicht so viel mit Chrome zu tun hatte. Australis ist mehr als die Tab-Form, Gleiches gilt für das kommende Chrome-Design. Die Leute schreien viel zu schnell "Kopie".

    In dem Fall wünschte ich allerdings, Google würde kopieren. Mir hatte, was Firefox betrifft, Australis gefallen (auch wenn ich Photon definitiv besser finde). Mir hat aber auch das bisherige Design von Chrome gut gefallen (mit Abstrichen), daher ist das keine Mozilla-/Google-Sache, das Chrome-Design war in meinen Augen gute Arbeit. Ein Chrome mit Australis-Zügen: kann man vielleicht machen. Aber das, was ich da vorhin in meinem Chrome Canary aktiviert habe, ist von allen Browsern, die ich installiert habe, für mich das schlimmste Design. :)

    RedSign hat natürlich recht, es ist eine Canary-Version, insofern warte ich da auch mal entspannt ab. Während der Implementierung von Australis oder Photon sah die Nightly-Version von Firefox ja auch zeitweise eigenartig aus.

    Mal ein Screenshot für die anderen Nutzer, die kein Chrome Canary installiert haben.