Entwicklung Firefox

cool :klasse:
EDIT: ich frage mich nur ob das nicht auf Dauer Probleme bereiten könnte, denn es wurde ja auf ein http Bild in Beitrag #7 verwiesen und nun wird der Link auf https umgeleitet. Im Quelltext der Seite wird weiterhin (das muss wohl auch so sein) http angezeigt.
Also ich meine Probleme in dem Sinne, dass zb. https nicht mehr verfügbar ist (aus welchem Grund auch immer) oder das Zertifikat abgelaufen ist usw...
Aber ich lasse mich gerne überraschen.

Ich hab das mal eben etwas ausführlicher (mit 952 Wörtern) in einem Artikel verpackt, um das genau zu erklären.

Für die "Newsletter-Liebhaber", es gibt nach ein paar Monaten Pause wieder die wöchentlichen Newsletter über die Entwicklungen der Servo-Engine!

https://blog.servo.org/2018/02/26/twis-105/

Einige der Tickets erkenne ich aus den WebRender Tickets wieder. Ich hatte bisher aber den Eindruck dass sich die Implementation in Firefox und Servo teils grundlegend unterscheiden würde. Ist dem nicht so?

WebRender ist eine Servo-Komponente. Für die Integration in Firefox ist noch die Gecko-Seite wichtig. Die WebRender-Newsletter sind ja immer zweigeteilt: ein Abschnitt benennt die Änderungen auf Servo-Seite, ein Abschnitt die Änderungen auf Gecko-Seite.

Mit identity.fxaccounts.enabled gibt es eine neue Option in about:config, um Sync aus den Firefox-Einstellungen auszublenden.

Und Themes können nun auch die ganzen Menüs verändern:

[attachment=0]themes.png[/attachment]

(das dunkle Firefox-Theme wird davon auch bald Gebrauch machen.)

Ein Nachrichtenzentrum für Firefox:
[Blockierte Grafik: https://screenshotscdn.firefoxusercontent.com/images/b19d08c…58dee278b2b.png]
https://mozilla.invisionapp.com/share/7KFW0HQNU86#/screens

^ Geplant für Firefox 61.

Wenn wir schon beim Activity Stream sind, noch für Firefox 60 geplant, hier die geplanten neuen Einstellungen - die Einstellungen werden alle in die Haupt-Einstellungs-Seite integriert:

[attachment=0]firefox-home.png[/attachment]

https://mozilla.invisionapp.com/share/EGFI16P8…reens/280785532

Hier mal ein aktueller Graph zur Entfernung von XBL aus Firefox (Code-Zeilen):

[attachment=0]de-xbl.jpg[/attachment]

(https://twitter.com/mike_conley/status/968900019888762881)

Gutes Tempo. Wenn es so weiter geht, dürfte XBL in gut einem Jahr Geschichte sein.

Gibt es eigentlich nach der Entfernung der letzen Zeile XBL noch weitere Sachen die erst dann komplett gelöscht werden können? Wie Libraries etc.?

XUL. XBL definiert ja das Verhalten von XUL-Widgets.

Ansonsten diese DOM-Events sind auch nur XBL da:
https://bugzilla.mozilla.org/show_bug.cgi?id=662335

Ein wichtiger Aspekt ist aber auch, dass das halt proprietäre Mozilla-Technologie mit eigenen Verhaltensweisen ist, was eine hohe Hürde für andere ist, zur Entwicklung von Firefox beizutragen, weil erst etwas gelernt werden muss, was nur in Firefox existiert. Wird nur noch Webtechnologie verwendet - und XBL kann durch Webtechnologie wie Shadow DOM und Web Components ersetzt werden -, senkt das diese Hürde, wovon Firefox als Ganzes profitiert, ganz unabhängig von Dingen, die entfernt werden können, wenn XBL nicht mehr da ist.

Was haben andere Browser statt XBL verwendet? Shadow DOM und Web Components gibt es ja noch nicht so lange?

Andere Browser verwenden kein XUL, die brauchen dementsprechend auch kein XBL. Die meisten Desktop-Browser haben ihre Oberfläche in C++ programmiert. Der Internet Explorer verwendet definitiv C++, Google Chrome ebenfalls auf Windows und Linux, auf macOS stattdessen Objective C, plus eben entsprechender UI-Bibliotheken. Auf macOS wäre das Cocoa, auf Windows ist es deren eigene Entwicklung Aura, auf Linux war es früher GTK+, jetzt ist es dort auch Aura.

So soll die neue Bibliothek im Tab aussehen:

[attachment=0]library.png[/attachment]

(https://mozilla.invisionapp.com/share/WUG3C3PV…reens/281925506)

Das heißt XUL definiert nur wie die Oberfläche des Browsers WebTechnologien (HTML etc.) interpretiert?

XUL ist eine Alternative zu HTML wie Fokus auf Programmoberflächen, XBL definiert durch sogenannte Bindings das Verhalten von XUL-Widgets. Beides wird nur von der Gecko-Engine verstanden. XUL und XBL gehen also Hand in Hand. Beides ist zu einer Zeit enstanden, in der HTML und JavaScript noch nicht auf dem Stand waren, auf dem sie heute sind. Damals brauchte Mozilla die eigene Technologie, wenn sie die Oberfläche von Firefox mit web-ähnlicher Technologie umsetzen wollten. Sie hätten die Oberfläche natürlich auch ganz klassisch wie andere Anwendungen umsetzen können, dann würde es heute Dinge wie userChrome.css nicht geben.

Übrigens, Fun Fact: Heutige Webstandards, die XUL und XBL verdrängen, wie beispielsweise CSS Flexbox oder Web Components, sind stark von Mozillas Technologien XUL und XBL inspiriert. Mozilla hat hier also (einmal mehr) Pionier-Arbeit geleistet. Und nun ist es eben an der Zeit, XUL und XBL in Rente zu schicken. Sie haben zu einem besseren Web beigetragen, aber heute ist es eben nur noch proprietäre Technologie, die nicht das Web ist.

Was genau bedeutet es Buildbot nicht für einen Release zu benutzen:
https://twitter.com/chrisatlee/status/969294182497095680

Nichts, was für den Endanwender relevant ist, das ist ein reines Release Engineering-Thema. Buildbot [1] ist ein Tool für Continous Integration [2] und wird letztlich auch dafür verwendet, die Firefox-Builds zu erstellen. Mozilla verwendet nun Taskcluster [3], das eine Eigenentwicklung von Mozilla.

[1] https://buildbot.net/
[2] https://de.wikipedia.org/wiki/Kontinuierliche_Integration
[3] https://github.com/taskcluster

So viel habe ich auch verstanden, ich habe mich nur gefragt wieso es etwas positives ist einen Release ohne Buildbot machen zu können?

Weißt du eigentlich wie weit das neue Lokalisationssystem von Mozilla ist? Sollte das nicht auch bedeuten, dass Lokalisationen nicht mehr fest in der Exe integriert sind, sondern wie bei Chrome bspw. dynamisch nachgeladen und gewechselt werden können?