Entwicklung Firefox (Trunk)


  • Die Nightly für Windows von heute Nacht ist die erste, die mit Clang kompiliert wurde :D

    Warum nur für Windows?
    Mir ist die Relevanz dieser Plattform bekannt. Nur sollte beim Start einer neuen Umgebung der Test nicht gleich künstlich eingeschränkt werden.

  • Zunächst einmal sind das Kompilieren für Windows, macOS und Linux drei voneinander vollkommen unabhängige Baustellen. Überall den gleichen Compiler nutzen zu können, hat natürlich Vorteile, aber es hätte bei der Komplexität der ganzen Build-Infrastruktur nicht viel Sinn, eine Plattform von einer anderen abhängig zu machen. Das heißt, ob Mozilla die Windows-Versionen mit Clang kompiliert oder nicht, ist für macOS und Linux egal.


    Eine Einschränkung liegt nicht vor. Auf macOS und Linux kann Firefox eh schon ziemlich lange mit Clang kompiliert werden. De facto zeigt mir Firefox auf macOS in about:buildconfig an, dass die macOS-Version auch mit Clang kompiliert ist. Für Linux müsstest du selbst prüfen, womit die offiziellen Mozilla-Builds (oder die deiner Distribution) kompiliert werden, das weiß ich nicht. Aber das Ergebnis würde mich interessieren, falls du nachsehen magst.


    Aber wenn es um Linux geht, ist eines noch wichtig: Linux-Distributionen treffen hinsichtlich des Compilers sowieso ihre eigenen Entscheidungen für ihre Pakete und die nutzen für Firefox häufig eh nicht den gleichen Compiler wie Mozilla (selbst wenn es nur eine andere Version ist, es gibt meistens Unterschiede). Das heißt, wenn du Firefox von deiner Distribution beziehst, ist Mozillas Compiler-Wahl für dich eh nicht relevant. Firefox kann in jedem Fall auf jeder Desktop-Plattform mit Clang kompiliert werden, das ist nicht auf Windows beschränkt.

  • Mal kurz bei Mozilla nachgeschaut:

    Code
    1. /builds/worker/workspace/build/src/gcc/bin/gcc -std=gnu99 6.4.0 -Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wduplicated-cond -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wformat -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe
    2. /builds/worker/workspace/build/src/gcc/bin/g++ 6.4.0 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wduplicated-cond -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wformat -D_GLIBCXX_USE_CXX11_ABI=0 -fno-sized-deallocation -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -O3 -fno-omit-frame-pointer


    Und hier die Distribution:

    Code
    1. /usr/bin/gcc -std=gnu99 7.3.0 -Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wduplicated-cond -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=free-nonheap-object -Wformat -Wformat-security -Wformat-overflow=2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe
    2. /usr/bin/g++ 7.3.0 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++1z-compat -Wduplicated-cond -Wimplicit-fallthrough -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=free-nonheap-object -Wformat -Wformat-security -Wformat-overflow=2 -fno-sized-deallocation -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -freorder-blocks -O2 -fno-omit-frame-pointer


    Beide nutzen gcc, nur lädt Mozilla einen älteren Compiler.
    Aber ich kann es ja abwarten. Der Fx ist hier auch so schon schnell genug.

  • Danke für die Info, dann bin ich hier auch wieder up-to-date. ;)


    Ich habe mal nach Plänen für Linux gesucht. Interessanterweise hat Mozilla vor etwas mehr als einem Monat erst auch die lokalen Entwickler-Builds unter Linux von GCC auf Clang umgestellt:


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


    Allerdings bislang nur diese und nicht die Release-Builds.

  • Hallo, kennt einer den Grund warum about:config -> "browser.showQuitWarning" in Firefox 63.0a1 nicht mehr vorhanden ist?
    In Bugzilla.mozilla.org habe ich dazu keinen Hinweis gefunden. Ich habe diese Einstellung immer gerne auf true gestellt, weil ich gefragt werden wollte, ob die Session gespeichert werden soll oder nicht.
    Gruß und Dank,
    MrX1980

    HauptPC: ASRock X99M Extreme4; i7-5820K; 4x4GB DDR4-2400; Gigabyte GTX 1060 6GB Mini OC; 950 Pro 512 GB
    ZweitPC: Asus M4N82 Deluxe; Phenom II x6 1090T; 4x2GB DDR2-800; GeForce GT530
    TestPC: Gigabyte GA-K8NS Pro; Athlon 64 Venice 3200+; 2x 1GB MDT DDR-400; Club3D HD4670 AGP
    Notebook: ASUS K53SV; i5-2410M/HD3000; GeForce 540M 2GB; 2x4GB DDR3-1866: 850 EVO 500 GB


  • Hallo, kennt einer den Grund warum about:config -> "browser.showQuitWarning" in Firefox 63.0a1 nicht mehr vorhanden ist?
    In Bugzilla.mozilla.org habe ich dazu keinen Hinweis gefunden. Ich habe diese Einstellung immer gerne auf true gestellt, weil ich gefragt werden wollte, ob die Session gespeichert werden soll oder nicht.


    Dazu gehört dieses Ticket:
    https://bugzilla.mozilla.org/show_bug.cgi?id=1438499


  • Nutzt hier eigentlich jemand den Bookmark Mirror (services.sync.engine.bookmarks.buffer)? Ich habe den ein paar Wochen genutzt und jetzt wieder deaktiviert weil er noch sehr buggy ist (Bookmarks werden tlws. nach dem Verschieben wiederholt wieder in andere Ordner zurückverschoben oder dupliziert), zudem ist die Performance tlws. echt schlecht. Ich hatte Situationen mit einem starken i7 6700k, in denen ich mehrere Sekunden warten musste, bis das Dialogfeld zum Bookmarksetzen aufging. In der Zeit war die gesamte Bookmark-Funktion lahmgelegt.


    Die Performanceprobleme sind mit dem Fix in der heutigen Nightly verschwunden :D

  • Siehst du, das Melden von Problemen kann sich lohnen. :) Vielleicht tut sich bei deinem zweiten Ticket ja auch noch was, ein bisschen Aktivität gab es da ja schon. Aber wegen der aktuellen Wartungsarbeiten (wenn ich gemein wäre, würde ich sagen: acht Stunden geplante Bugzilla-Downtime für ein paar Emojis :P) kann ich gerade nicht den aktuellen Status prüfen.

  • Offenbar, danke fürs Motivieren Sören :) Das andere Ticket habe ich ein wenig beobachtet, konnte das aber zuletzt nicht mehr beobachten. Könnte mir vorstellen dass es entweder ein Effekt beim Synchronisieren von Profilen mit Bookmark Mirror und ohne Bookmark Mirror ist, bzw. das mit dem anderen Ticket zusammenhing oder generell in dem Profil mit der Desktopinstallation irgendeine Form der Korruption vorliegt/lag.

  • Die automatische Installation von Updates kann immer noch über die Firefox-Einstellungen deaktiviert werden, aber die Option, nach Updates nicht einmal suchen zu lassen, wurde entfernt. Auch die dazugehörige Einstellung app.update.enabled in about:config existiert nicht länger. Das geht nur noch über die Policy Engine (wobei meine Erweiterung helfen kann: https://addons.mozilla.org/de/…erprise-policy-generator/; auch wenn da steht, dass das nur mit Firefox ESR geht, das geht ab Firefox 62 auch im Mainstream-Firefox).


    Aber ich kann nur betonen, dass es (bis auf ganz spezielle Ausnahme-Situationen) keinen guten Grund dafür gibt, Updates vollständig zu deaktivieren.

  • Firefox Nightly 63 unterstützt nun Version 1.0 des neuen AV1 Video-Codecs (wenn auch noch standardmäßig deaktiviert):
    https://bugzilla.mozilla.org/show_bug.cgi?id=1445683


    AV1 ist eine Riesen-Sache. Ein gegenüber H.264 deutlich überlegender Video-Codec, der dazu komplett lizenzfrei ist, was H.264 eben nicht war. Auch wenn wir als Nutzer für Videos nichts bezahlen müssen, dann häufig nur, weil andere Firmen Millionen dafür gezahlt haben. Mozilla sagt, dass das bei 80 Prozent aller Videos der Fall ist, die wir im Web betrachten. Um die Überlegenheit in ganz einfachen Zahlen auszudrücken: Mit AV1 bekommt man Videos mit vergleichbarer Qualität wie bei H.264 in etwa gerade mal der halben Dateigröße hin.


    Entwickelt von der Alliance for Open Media, zu deren Gründungsmitgliedern nicht nur Mozilla zählt, sondern auch andere große Namen wie Google, Microsoft, Intel, Cisco, Amazon und Netflix, mittlerweile im Vorstand ergänzt von Apple, ARM, Facebook, IBM und Nvidia. Große Namen wie Adobe, hulu, VLC, Vimeo, Realtek, Vidyo, BBC und noch einige mehr haben sich ebenfalls angeschlossen. Also dass in diesem Codec die Zukunft liegt, davon kann ausgegangen werden. Ich sags's ja: große Sache. Daher meine Euphorie. :D

  • … und nicht zu vergessen für die Portale deutlich reduzierte Kosten, was uns indirekt ebenfalls betrifft. Können Kosten eingespart werden, müssen weniger nervende Maßnahmen ergriffen werden, um die Ausgaben zu decken und profitabel zu sein. Kommt das Geld nicht rein, muss es über Werbung und oder Bezahlmodelle reinkommen, im schlimmsten Fall führt es gar zur Schließung des Portals, weil die Verluste nicht mehr aufgefangen werden können. Selbst ein Riesen-Portal wie YouTube hat im Jahr 2015, also noch gar nicht lange her, vier Milliarden Dollar Umsatz und damit nicht einen Cent (!) Gewinn gemacht (Quelle: Wall Street Journal). Das sollte man also nicht unterschätzen, wie teuer der Betrieb einer solchen Plattform ist. Neben Google hätte sich das wohl kaum ein Unternehmen leisten können. Und ich glaube, auf YouTube will heute kaum noch jemand verzichten.

  • Ja, auf jeden Fall. Kein Wunder also, dass sich praktisch alle grossen Namen an der Entwicklung beteiligen. :)

    Windows 10 | FF 62.0 (64-Bit) / FF 61.0 (64-Bit) / FF 63.0 (64-Bit)

  • Allerdings sind die Encoder bisher noch sehr langsam und der Hardwaresupport beim Decoding fehlt noch. Dennoch langfristig natürlich eine tolle Sache dass es breit unterstützte Konkurrenz zu HEVC gibt.