Entwicklung Firefox

    So viel ich früher einmal gelesen habe werden die Nightlis nicht auf Funktionsfähigkeit überprüft.
    Der Code wird zu einer bestimmten Zeit in den Compiler geschoben ob er funktioniert oder nicht.
    Genaueres kann bestimmt Sören erzählen.

    WIN11 Home Version 23H2 (Build 22631.4541)

    Firefox 132.0.2(64-Bit)

    Thunderbird 128.4.3esr (64-Bit)

    Meine Erweiterungen

    Grundsätzlich landet nichts ungeprüft im Code. Jeder Patch, welcher geschrieben wird, erhält mindestens ein Review durch einen anderen Entwickler, und das so viele Runden, bis dieser Überprüfer ein "Review+" gibt. Handelt es sich um eine größere Änderung, welche die Architektur betrifft oder APIs ändert, ist außerdem zusätzlich noch ein Super Review vom Module Owner notwendig, also demjenigen, welcher die Verantwortung für eine Komponente trägt.

    Für manche Änderungen werden häufig sogenannte Trybuilds erstellt. Das sind spezielle Testbuilds, um Änderungen in realen Builds zu testen. An diesem Punkt wurde noch nichts in den Hauptentwicklungszweig integriert. Für größere Änderungen wird ein ganz eigener Entwicklungszweig benutzt, welcher zu einem späteren Zeitpunkt in den Hauptentwicklungszweig integriert wird.

    Und dann gibt es noch zahlreiche automatisierte Tests. Das ist der Kernpunkt. Mozilla akzeptiert keinen Code, für welchen keine Tests existieren. Gegebenfalls muss der Entwickler eben Tests schreiben.

    Im Prinzip landet gar keine Änderung direkt im Hauptentwicklungszweig. Es gibt sogenannte Integrationszweige (inbound, fx-team u.a.). Änderungen landen grundsätzlich in Integrationszweigen. An diesem Punkt finden diese Tests statt, genauso auch bei den Trybuilds. Wenn Tests fehlschlagen, werden Änderungen wieder aus dem Zweig entfernt. Und wenn die Integrationszweige mit dem Hauptentwicklungszweig zusammengeführt werden (das geschieht täglich), finden diese Tests wieder statt. Dieses Vorgehen nennt man Continous Integration. Mozilla betreibt das über ein System, welches sich Tinderbox nennt. Das hat Mozilla selbst entwickelt.

    Genau diese häufige Integration ist das Konzept und fördert im Gesamten die Code-Qualität. Eine Release-Qualität darf man aber nicht zu diesem Zeitpunkt erwarten, es sind und bleiben Nightly-Builds und damit die allerersten Alpha-Versionen. Vor allem sind das aber alles automatisierte Prozesse, es ist für Menschen gar nicht möglich, jeden Build vor Ausgabe zu überprüfen und streng genommen gibt es auch gar keine Ausgabe, Nightly-Versionen sind keine offiziellen Release-Builds. Über die Seite der Downloads für die verschiedenen Mozilla-Kanäle gibt es Downloads erst ab Aurora. Nicht grundlos gibt es für Nightly-Versionen eine ganz eigene Seite.

    Nichtsdestominder betreibt Mozilla einen gigantischen Aufwand zur Qualitätssicherung und das zahlt sich aus, Firefox ist der Browser mit den wenigsten Abstürzen.

    Und speziell zu diesem Problem: Wenn wir von Darstellungsproblemen reden, dann ist zumeist die Hardwarebeschleunigung und damit die Grafikkarte und dazugehörigen Treiber involviert, genauso wie das Betriebssystem. Das hängt sehr, sehr stark von der Kombination aller Faktoren ab, so dass viele dieser Probleme nur bei einem Teil der Nutzer auftreten, so dass die Entwickler unter Umständen gar nichts davon wissen, bis ein Bug angelegt wird. Aber genau das sollte die Sache sein, wieso man eine Nightly-Version nutzt. Niemand sollte das tun, nur um früher alles zu haben. Wer eine Nightly-Version nutzt, sollte Fehler erwarten und diese auch melden. Der Grund, wieso es relativ häufig "Punkt-Releases" von Firefox gibt, ist der, dass selbst in der Betaphase zu wenige Menschen testen und auch wirklich Probleme melden. Nach Veröffentlichung der finalen Version ist es definitiv zu spät.

    Zitat von Sören Hentzschel

    Wer eine Nightly-Version nutzt, sollte Fehler erwarten und diese auch melden


    1. Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0
    2. Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0
    3. UX Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0

    Rennen hier wie Sau. So etwas wie Abstürze sind hier unbekannt.
    Zugegeben, ich benutze obige Herde nur, ein "Testszenario" habe ich nicht, aber bislang hat mich kein Fx im Stich gelassen.

    Gut, dann ist es wahrscheinlich, dass dieser Bug dazu gehört, auch wenn im Titel von Thunderbird die Rede ist, der Bug befindet sich in der Layout-Komponente und gehört damit auch zu Firefox. Dort ist einem Kommentar auch von Firefox UX die Rede, passt also.

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

    Sollte es sich bei eurem Problem darum handeln (ich kanns nicht testen, hab erst nächste Woche wieder Windows zur Verfügung), dann ist der schuldige Bug bereits identifiziert.

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

    Hallo Sören.
    Danke für die Info.
    Besonderen Dank für den Tipp für den about:config Schalter.
    Damit funktioniert es hier in allen drei (Firefox 26, 32 bit, sowie 64 bit und Firefox UX) wieder einwandfrei.
    :klasse:

    Mfg.
    Endor

    Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
    OS: Windows 10 pro 64 bit und Windows 10 Home 64 bit
    Meine Scripte Sammlung: https://github.com/Endor8/userChrome.js
    Kein Support per PN. Fragen bitte im Forum stellen!

    Boersenfeger: Kann es sein, dass du die Hardwarebeschleunigung deaktiviert hast? Dein Screenshot mit den schwarzen Flächen sieht mir nach dem folgendem Bug aus und tritt nur bei deaktivierter (!) Hardwarebeschleunigung auf.

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

    Ursächlich dafür ist genau der gleiche Bug wie für das Scroll-Problem, den ich im letzten Beitrag bereits erwähnt habe. Das wurde aufgrund der zahlreichen Regressionen nun deaktiviert, also ab dem morgigen Nightly sollte dann wieder alles wie gewohnt laufen.

    /*
    Diesmal als reiner Kommentar, weil ich manche Welten nicht verstehe,

    Was geht einem Anwendungsprogramm eigentlich die Hardwarebeschleunigung an ?
    Die sollte eigentlich transparent verfügbar sein. Ein OS unterstützt sie oder auch nicht.
    Warum muss eine Anwendung darum ein Gehampel programmieren ? Ich verstehe es nicht.

    Dies von einem OS geschrieben, das noch nie optische Probleme verursacht hat.
    Darum der reine Kommentar.
    */

    Zitat von Sören Hentzschel

    Boersenfeger: Kann es sein, dass du die Hardwarebeschleunigung deaktiviert hast?

    Das ist richtig... mit dem heutigen UpDate und der Aktivierierung der HWB sind beide Phänomene verschwunden... (hier zumindest)

    Zitat von .Hermes

    Warum muss eine Anwendung darum ein Gehampel programmieren ? Ich verstehe es nicht.

    Ganz einfach, weil es so simpel wie dargestellt in der Realität nun einmal nicht ist. Es kommt auf ein perfektes Zusammenspiel zwischen allen beteiligten Komponenten an und das ist eben häufig nicht so perfekt, weil es Bugs auf OS-Ebene gibt, weil es Fehler in den Treibern gibt (ganz schlimm!), weil teilweise sogar die Grafikkarten fehlerhaft sind und natürlich hat auch Firefox seine ganz eigenen Bugs und wahrscheinlich sogar grundlegende Probleme in der Architektur, da Firefox teilweise von Fehlern in diesen anderen Komponenten betroffen ist, Mozilla es aber nicht schafft, um diese herumzuarbeiten, während es anderen Browserherstellern gelingt.

    Und um auf möglichst vielen Plattformen die bestmögliche Performance herauszuholen, muss Mozilla verschiedene Backends für diverse Aufgaben pflegen und das ein enormer Aufwand. Natürlich könnte es Mozilla deutlich einfacher haben, wenn sie kein Gehampel darum machen, dann läuft Firefox halt entsprechend schlechter. Die Grundidee ist ja vollkommen richtig: Die Hardware ist vorhanden, also sollte der Browser diese auch nutzen, dafür ist sie schließlich da. Es werden heute enorme Anforderungen an einen Browser gestellt, im Jahr 2013 hat man spätestens angefangen zu erwarten, dass 3D-Spiele flüssig so langsam mal im Browser funktionieren. Nur als Beispiel. Es gibt noch ganz andere komplexe Anwendungen als Spiele, das war nur ein naheliegendes Beispiel, wo Mozilla ja kürzlich die Unreal 3-Engine für das Web portiert hat.