Entwicklung Firefox

Wenn ich Webrender einschalte steht da: available by user: Qualified enabled by pref.
Und das war vorher so nicht der Fall.

WEBRENDER
opt-in by default: WebRender is an opt-in feature
Steht da per default bei mir.

Also ausgehend vom Code in gfxPlatform.cpp ist 0x67ef bei den Grafikkarten dabei, für die WebRender aktiviert worden ist. Ich gehe mal davon aus, dass du immer noch eine Nightly-Version von Firefox nutzt, weil das nur für Nightly-Versionen gilt. Ansonsten trifft vielleicht ein anderes Ausschlusskriterium zu. Aber so oder so, ich denk mir, wenn WebRender standardmäßig deaktiviert ist, wird's dafür Gründe geben und ich würd einfach warten, bis sich das wieder ändert. Ansonsten bleibt eh der genannte Schalter, um Webrender wieder zu aktivieren.

Wo wir schon bei WebRender sind: Der offizielle Rollout wird ja bekanntermaßen mit Firefox 67 starten, aber bereits in Firefox 66 wird WebRender schon für 0,06 Prozent der Nutzer aktiv sein, um bereits ein paar Daten von der Release-Population zu erhalten.

HeinzDo... du hast ja Windows neu installiert, hast du auch direkt von Nvidia die neusten Treiber installiert?

Zitat von AngelOfDarkness

HeinzDo... du hast ja Windows neu installiert, hast du auch direkt von Nvidia die neusten Treiber installiert?

Ja, den neueste AMD-Grafikkartentreiber habe ich natürlich installiert.

Achtung, das heutige Nightly-Update hat meine komplette Sitzung zerschossen (Windows x64)...

Zitat von Lurtz

hat meine komplette Sitzung zerschossen (Windows x64)...

Kann ich bei mir nicht bestätigen. Sitzung ist bei mir weiterhin vollständig vorhanden, und wird auch korrekt nach dem Beenden wiederhergestellt.

Mit 67.0a1 (2019-02-26)? Vielleicht war es auch ein ganz unglücklicher Shutdown Crash. Hast du angepinnte Tabs?

Ja, hab immer die aktuellste Nightly Version installiert. (->ergo vom 26.02). Angepinnte Tabs habe ich hingegen keine.

Könnte mir vorstellen dass es daran liegt: https://bugzilla.mozilla.org/show_bug.cgi?id=1442694#c44

Hier kein Problem:

https://hg.mozilla.org/mozilla-central/rev/110ea2a7c3d4f34b5079c195f7ea57966748e6da
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0 ID:20190226093755

Keine gepinnten Tabs!

Das Problem ist bekannt, darum sind Nightly-Updates auf neuere Versionen als die gestrige mittlerweile auch deaktiviert. Und ja, die in Beitrag #5482 verdächtigte Änderung ist Schuld.

Bei sowas frage ich mich immer ob man sowas nicht vorher testen könnte (also tatsächlich auch durch Unit Tests etc.) Ich meine sowohl Pinned Tabs als auch Session Restore sind jetzt keine obskuren Kombinationen, da könnte man ja vermuten dass eine solche Änderung was kaputt machen könnte.

Die Nightly-Versionen sind ja dafür da, solche Dinge zu testen. Ansonsten stimmt es natürlich grundsätzlich, dass automatisierte Tests im Idealfall möglichst viele Fehler abfangen, nur manchmal merkst du erst, dass ein Test fehlt, wenn das Problem in der Praxis auftritt. Tests können ja auch immer nur genau das abfangen, wofür sie programmiert worden sind. Aber der Schaden ist ja gering. Die Sitzung ist im Profilverzeichnis gesichert und kann wiederhergestellt werden. Nutzer finaler Versionen sollten sowas nicht müssen, aber Nightly-Nutzer können das hoffentlich.

Schon, aber Mozilla hat ja hart daran gearbeitet die Nightly-Population zu vergrößern indem man vieles in der Nightly stabiler gemacht hat. Im Ticket kam jetzt auch die Frage auf, ob man sowas nicht durch Tests hätte abfangen können, insofern war der Gedanke wohl nicht ganz abwegig

Wie gesagt: Tests können immer nur genau das abfangen, wofür sie programmiert worden sind. Das Anheften von Tabs ist ein Feature, welches Firefox seit Jahren hat und Tests besitzt. Insofern programmierst du dafür keinen Test, wenn du daran arbeitest und nicht davon ausgehst, dass du damit einen Pfad auslöst, welcher ungetestet ist. Viel mehr gehst du als Entwickler davon aus, dass einer der Tests angeschlagen wäre, wenn ein Problem vorliegt. Und das meinte ich in meinem vorherigen Beitrag mit: manchmal merkst du erst, dass ein Test fehlt, wenn das Problem in der Praxis auftritt. Ich kenne das Dilemma als Entwickler nur zu gut.

Aber schreibt man bei testgetriebener Entwicklung nicht schon vor jeder Neuprogrammierung einen Test, der die Szenarien alle überprüft?

Ich bezweifle mal, dass bei Mozilla sehr viel Test Driven Development betrieben wird, denn das würde bedeuten, dass die Tests vor der eigentlichen Programmierarbeit geschrieben werden, und meiner Erfahrung nach passiert das meistens umgekehrt.

Dass immer jedes denkbare Szenario abgedeckt ist, funktioniert in der Theorie. Aber selten in der Praxis, in der Software von Menschen entwickelt wird. Das wäre vermutlich der Beginn fehlerfreier Software.

Wo wir es von Tests hatten: Für meinen neuesten Beitrag zum Firefox-Quellcode musste ich auch Tests schreiben. Keine Probleme auf macOS, aber ein Try-Run gerade eben ergab, dass sie auf Windows und Linux nicht durchlaufen und ich hab keine Ahnung, wieso sie das nicht tun. Tests sind toll, im Ernst, aber es ist eine Hassliebe…

---

Wer sich noch fragt, ob es wirklich so einen Unterschied macht, Rust anstelle von C++ als Programmiersprache zu verwenden:
https://hacks.mozilla.org/2019/02/rewrit…ponent-in-rust/

Demnach hat es in Firefox seit dem Jahr 2002 69 Sicherheitslücken in der Style-Komponente gegeben, also der Komponente, welche für das CSS von Webseiten verantwortlich ist. Von den 69 Sicherheitslücken wären 51 gar nicht erst möglich gewesen wären, wäre von Anfang an Rust verwendet worden. Rust kann Sicherheitslücken auch nicht komplett verhindern, das wird in dem Artikel auch deutlich gemacht, aber die Zahl ist schon beeindruckend.

Blöde finde ich die Tests vor allem dann wenn sie nur theoretischer Natur sind und in Wirklichkeit gar keine Auswirkung haben für den Nutzer oder die Software, dann ist es nervig. Du könntest ja eine VM mit Windoof und Linux machen? Ersteres kannst du ja 30 Tage ohne Lizenz laufen lassen.

30 Tage bringt mir nichts, ich trage ja nicht nur einmal bei. Außerdem geht's ja auch nicht primär um das System, sondern darum, dass mir der Lösungsansatz fehlt. Aber das ist wohl wirklich nicht ganz einfach. Die Fixes, die ein Firefox-Entwickler nun versucht hat, haben auch nicht funktioniert, weswegen der nur sein Windows-System rauskramen muss.