Entwicklung Firefox

Zitat von AngelOfDarkness

Jetzt nervt nur noch Simple Tab Groups herum mit seinen Benachrichtigungen. Aber ich denke da ist der Autor eh am Ball.

Du meinst vermutlich die Benachrichtigungen darüber, dass die Erweiterung einen Fehler wirft und man den Entwickler benachrichtigen soll. Das ist eine Folge von:

Es wäre naheliegend gewesen, aber nein, das steht nicht in Zusammenhang mit Mozillas Arbeit an Tab-Gruppen. Mozilla hat den Entwickler der Erweiterung bereits über die Ursache benachrichtigt.

Die Nigthly unter Debian hier hat sich auf die Version vom 31.1. aktualisiert, es gibt wieder Updates

Die gab es bei mir jeden Tag unter Debian und dem Repo von Mozilla.

Mit entsprechendem Erfolg, oder auch nicht, wie du erlebt hast. Du bist ein Nutzer derjenigen, die das Update vor Aussetzen erhalten haben.

Und trotzdem war nichts mit aussetzen bei mir. Ich habe allmorgentlich meine Updates für die Nigthly bekommen. Deswegen habe ich ja auch Dienstag die Nightly, ohne dem Patch der zu der Regression geführt hat, bekommen.

Bei sowas passe ich kurzfristig dann meine policies an und gehe eine Nightly zurück, ist ja machbar. Bis das Problem erledigt wird. Wobei die Nightly bei mir keine Probleme bereitet, an die ich mich erinnere. Ich nutze die selten, und die beta noch weniger. Deswegen fällt mir sowas nicht auf, und falls doch, suche ich nicht nach bugs oder melde es, sondern nutze es einfach nicht, so wichtig ist mir Nightly nun wieder nicht.

Ich mag das neue Firefox-Logo.

(Firefox 136+, nur temporär, mit browser.newtabpage.activity-stream.newtabLogo.aprilfools auf true. Wie der Name andeutet, dürfte das am 1. April aktiviert und anschließend wieder deaktiviert werden.)

Jag mir bitte nicht so einen Schreck ein

Zitat von Sören Hentzschel

Ich mag das neue Firefox-Logo.

Ich finde es sieht so aus, als ob er gleich runterfällt, der Arme. 😢

Zitat von bege

Ich finde es sieht so aus, als ob er gleich runterfällt, der Arme.

Vielleicht ist der Designer aus Downunder.

Das Aprilscherz-Projekt wurde leider wieder gestrichen.

Ich hatte mich schon gewundert, als du Beitrag #6207 geschrieben hattest. Ich hatte nämlich gestern schon folgendes Ticket gefunden, hatte mir aber nichts weiter dabei gedacht:

Mit der morgigen Nightly-Version (Firefox 137) ändert sich die Syntax, um im CSS auf Optionen in about:config zu prüfen.

Bis Firefox 136:

@media (-moz-bool-pref: 'browser.foo.bar') {
  .selector {
    color: red !important;
  }
}

@media not (-moz-bool-pref: 'browser.foo.bar') {
  .selector {
    color: green !important;
  }
}

Ab Firefox 137:

@media -moz-pref('browser.foo.bar') {
  .selector {
    color: red !important;
  }
}

@media not -moz-pref('browser.foo.bar') {
  .selector {
    color: green !important;
  }
}

Ein Vorteil, der sich daraus ergibt: Bislang konnte so nur auf Boolean-Optionen geprüft werden. Die neue Syntax funktioniert auch für String- und Integer-Optionen. Dazu wird der Wert einfach als zweiter Parameter angegeben. Zum Beispiel:

@media -moz-pref('browser.foo.bar', 'value') {
  .selector {
    color: red !important;
  }
}

@media not -moz-pref('browser.foo.bar', 123) {
  .selector {
    color: green !important;
  }
}

Hat was

Ich hab grad (wieder) was in der Nightly gefunden:

Was der erste Screenshot zeigt, ist schon über drei Jahre alt und exklusiv für Nightly-Versionen. Die Kontrast-Einstellung ist aber tatsächlich neu und ersetzt die bisherigen Farbeinstellungen, die heutzutage für kaum eine Website noch relevant waren.

Das Thema CSP und das Anpassen von Inline-Event-Handlers war in den letzten Wochen und Monaten in Zusammenhang mit den Scripts ja relativ präsent in diesem Forum. Wer sich etwas für die Hintergründe interessiert, wieso Mozilla das gemacht hat (Mozilla selbst musste über 600 Inline-Event-Handler umstellen!), bekommt in Mozillas Sicherheits-Blog etwas Lesematerial:

Zitat von Sören Hentzschel

Das Thema CSP und das Anpassen von Inline-Event-Handlers war in den letzten Wochen und Monaten in Zusammenhang mit den Scripts ja relativ präsent in diesem Forum. Wer sich etwas für die Hintergründe interessiert, wieso Mozilla das gemacht hat (Mozilla selbst musste über 600 Inline-Event-Handler umstellen!), bekommt in Mozillas Sicherheits-Blog etwas Lesematerial:

https://attackanddefense.dev/2025/04/09/har…y-policies.html

Danke, Sören!

Ich habe in dem Text nicht verstanden, warum die Inline Eventhandler entfernt wurden. Dort steht doch, dass sie mit einer CSP gegen Missbrauch abgesichert werden können. Ich habe da noch eine Verständnislücke.

Eine Content Security Policy macht unsicheren Code nicht sicher, sondern bietet Sicherheit dadurch, dass die Ausführung von Scripts nur noch aus sicheren Quellen erlaubt wird. Das heißt zum Beispiel (CSP können unterschiedlich konfiguriert werden), dass Inline-Eventhandler verboten werden und nur noch der Code erlaubt wird, der aus Script-Dateien kommt.

Wenn man das von der Perspektive der Scripts betrachtet, die hier im Forum erstellt und geteilt werden, mag sich das nicht direkt erschließen, wieso addEventlistener() besser sein soll als setAttribute(). Beides sind Funktionen im Script, die letztlich das Gleiche ausführen. Dabei muss man aber bedenken, dass diese Scripts eine andere Ausgangslage als der Firefox-Code haben. Scripts verwenden deswegen setAttribute(), weil ja nicht die XUL- und HTML-Dateien von Firefox bearbeitet werden. Stattdessen muss alles im Script stattfinden. Und mittels setAttribute() wird aus einem Script heraus der Inline-Event-Handler im HTML oder XUL gesetzt, als stünde dieser von Anfang an dort.

Firefox hat jetzt (zumindest in der Datei browser.xhtml) keine Inline-Event-Handler mehr im HTML. Nachdem diese Voraussetzung geschaffen wurde, konnte mittels CSP die Verwendung von Inline-Event-Handlern generell verboten werden. Und aus diesem Grund können auch die hier besprochenen Scripts keine Inline-Event-Handler mehr setzen. Die CSP verhindert das. Die Ausführung von Scripts aus Script-Dateien ist nach wie vor erlaubt. Und da addEventlistener() den Handler nicht im HTML setzt, funktioniert das weiterhin.

Ich kan nicht in die Details gehen, wie Sicherheitslücken ausgenutzt werden können. Davon bin ich selbst thematisch zu weit entfernt. Aber die als Beispiel gebrachte Kette von Exploits in Firefox, die eben auch das Erstellen eines Inline-Event-Handlers über setAttribute() eingeschlossen hat, hat dem Entdecker beim Hacker-Wettbewerb Pwn2Own 2022 ein Preisgeld in Höhe von 100.000 USD gebracht. Ich denke, das sagt genug über die Wichtigkeit aus, die Möglichkeiten einzuschränken, an welchen Stellen Code ausgeführt werden kann. Natürlich bestand die Sicherheitslücke nicht alleine darin, sondern war eine Kombination aus mehreren Schwachstellen. Aber wären Inline-Event-Handler nicht erlaubt gewesen, wäre das ganze Angriffs-Szenario spätestens an dieser Stelle gescheitert.