Entwicklung Firefox (Trunk)

Du benötigst Hilfe bezüglich Firefox? Bitte stelle deine Frage im öffentlichen Bereich des Forums und nicht per Konversation an wahllos ausgesuchte Benutzer. Wähle dazu einen passenden Forenbereich, zum Beispiel „Probleme auf Websites“ oder „Erweiterungen und Themes“ und klicke dann rechts oben auf die Schaltfläche „Neues Thema“.
  • Hatte heute ein Ticket aufgemacht, aber das sollte ein Duplikat von dem sein, ja. Kommt auch zeitlich mit dem Landen von

    SessionHistoryInParent hin.

  • Eben in der Nightly gesehen, ist das schon bekannt?

    Zitat

    CSS: Constructable Stylesheets

    Durch das Hinzufügen eines Konstruktors zur CSSStyleSheet-Schnittstelle sowie einer Vielzahl damit zusammenhängender Änderungen können direkt neue Stylesheets erstellt werden, ohne dass das Sheet dem HTML hinzugefügt werden muss. Das macht es viel einfacher, wiederverwendbare Stylesheets für den Einsatz mit Shadow DOM zu erstellen. Weitere Informationen erhalten Sie im Bug 1520690.

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

    Sollte man echt jetzt an die shadow-Elemente rankönnen?


    rel=preload kann man hoffentlich abschalten später, ich mag kein Vorausladen von Seiten, die ich eh nicht besuche.

  • Sollte man echt jetzt an die shadow-Elemente rankönnen?


    Ich bin mir nicht sicher, was genau das meint, aber das Shadow DOM CSS konnte ja bereits von außen verändert werden: https://developer.mozilla.org/en-US/docs/Web/CSS/::part. Von der Datei userChrome.css wird das nicht unterstützt, daran ändert sich mit Constructable Stylesheets aber auch nichts. Auf https://developers.google.com/…constructable-stylesheets findet man eine Erklärung, was Constructable Stylesheets sind. Für Webentwickler sicher interessant, aber wirklich nur für die.


    rel=preload kann man hoffentlich abschalten später, ich mag kein Vorausladen von Seiten, die ich eh nicht besuche.


    Kann man, ich würde Performance-Verbesserungen aber nicht abschalten. Es werden damit keine beliebigen Seiten vorausgeladen, sondern Ressourcen (Schriften, CSS, Bilder, JS), die sowieso geladen würden. Dieser Mechanismus gibt Entwicklern mehr Kontrolle darüber, Anfragen zu priorisieren, um so die Geschwindigkeit zu optimieren.

  • Wie gesagt, rel=preload lädt nichts, was nicht sowieso geladen wird. Alles andere würde aus Entwickler-Sicht keinen Sinn ergeben, weil es dann nachteilig wäre. Eine Deaktivierung des Features bringt dir eine minimal verschlechterte Geschwindigkeit, ansonsten gar nichts. Daher würde ich mich auch nicht darauf verlassen, dass es die Einstellung, die es zur Deaktivierung gibt, für immer geben wird.

  • Die Aussage "Wer das als Entwickler benötigt" ergibt ja mal null Sinn. Der Entwickler hat doch nichts davon, der Nutzer profitiert davon. Genauso wenig Sinn ergibt, was du implizit damit aussagst, nämlich dass du nicht magst, wenn Websites schneller laden. Deine Aussage hat schon viel von reflexartiger Reaktion auf einen Begriff, ohne den technischen Hintergrund überhaupt verstanden zu haben. Die Anweisung signalisiert dem Browser lediglich, welche Ressourcen er priorisieren soll (und das ist auch nicht verbindlich), um sie bereits in den Browser-Cache zu laden, weil sie als erstes benötigt werden. Aber beim letzten Wort schließe ich mich dir an: Bitte. Wenn du so denkst: Bitte, dein gutes Recht. Nur wie gesagt glaube ich nicht, dass es dauerhaft möglich sein wird, das abzuschalten, weil es einfach keinen Anwendungsfall dafür gibt. Du hast offensichtlich eine völlig falsche Vorstellung von dieser Funktion. ;)

  • Du hast das mit dem Entwickler eingeworfen, mag sein, dass es hier falsch angekommen ist:

    Zitat

    Alles andere würde aus Entwickler-Sicht keinen Sinn ergeben

    Dass die Leute rund um Firefox wohl hauptsächlich Entwickler sind, war das klar, daher bin ich von Entwicklern mit/für Firefox ausgegangen, also Erweiterungen und co. Webseiten hatte ich nicht im Sinn.

    Zitat

    Web API: <link rel="preload">

    Das rel-Attribut mit dem Wert "preload" in einem <link>-Element soll dazu beitragen, Leistungssteigerungen zu erzielen, indem Sie Ressourcen früher im Seitenlebenszyklus herunterladen, damit sie früher verfügbar sind und weniger wahrscheinlich das Rendern von Seiten blockieren. Lesen Sie Preloading content with rel="preload" oder Bug 1583604 für weitere Details.

    Zitat

    Die Anweisung signalisiert dem Browser lediglich, welche Ressourcen er priorisieren soll (und das ist auch nicht verbindlich), um sie bereits in den Browser-Cache zu laden, weil sie als erstes benötigt werden.

    Das ist für mich nicht eines. Und diese Seite erklärt es noch anders:

    https://developer.mozilla.org/…b/HTML/Preloading_content


    Hier wird im head deklariert, was weiter unten benötigt wird. Das ist wohl die Langfassung vom Text in der Nightly, die sich wesentlich verständlicher liest als die Kurzfassung in Firefox/Einstellungen. So gesehen ist deine Aussage näher an MDN ran als die von Firefox dazu.


    Im Bereich Video/Audio werd ich mir dann ein Userscript schrauben, um das zu verhindern, alle anderen Ressourcen sind ok.

  • Du hast das mit dem Entwickler eingeworfen, mag sein, dass es hier falsch angekommen ist


    Der Entwickler einer Website muss entsprechende Anweisung in den Code einbauen, schließlich geht es hier um ein HTML-Feature. Aber kein Entwickler "benötigt das", es geht um eine Geschwindigkeits-Optimierung für den Endnutzer.


    Dass die Leute rund um Firefox wohl hauptsächlich Entwickler sind, war das klar, daher bin ich von Entwicklern mit/für Firefox ausgegangen, also Erweiterungen und co. Webseiten hatte ich nicht im Sinn.


    Zur Klarstellung, weil ich mir nicht sicher bin, ob es klar ist: Ich habe in diesem Zusammenhang nicht von Firefox-Entwicklern gesprochen. Als HTML-Feature betrifft dieses Feature Websites und ich meinte, dass es aus Sicht des Website-Entwicklers keinen Sinn ergeben würde, dem Browser zu signalisieren, dass eine Ressource vorausgeladen werden solll, die nicht sowieso geladen werden muss. Denn dann würde aus der Performance-Optimierung ja eine Performance-Verschlechterung werden, weil zusätzliche Inhalte geladen werden. Darum kann man ziemlich sicher annehmen, dass hierdurch nichts geladen wird, was nicht sowieso geladen wird. Nur eben früher im Ladezyklus der Website.


    Das ist für mich nicht eines. Und diese Seite erklärt es noch anders: […] So gesehen ist deine Aussage näher an MDN ran als die von Firefox dazu.


    Inhaltlich steckt da eigentlich nicht wirklich anderes dahinter. Mir fällt auf, dass du in deinem Zitat "in einem <link>-Element" fett markiert hast. Vielleicht liegt hier das Missverständnis vor: Ein <link>-Element ist kein Link auf eine andere Seite. MDN formuliert das so: "Das HTML-Link-Element (<link>) spezifiziert Beziehungen zwischen dem aktuellen Dokument und einer externen Ressource." In dem Fall bedeutet das, dass die Anweisung zum Preloading eben über ein <link>-Element stattfindet. Es geht aber immer um einzelne Ressourcen, sprich Schriften, Bilder, Scripts, CSS, …


    Im Bereich Video/Audio werd ich mir dann ein Userscript schrauben, um das zu verhindern, alle anderen Ressourcen sind ok.


    Du sprichst hier in der Zukunft, tatsächlich gibt es aber speziell für Video- und Audio-Elemente bereits seit zig Jahren ein preload-Attribut direkt im jeweiligen Element. Und wenn du dafür noch kein Script hast, erlaubst du das schon seit vielen Jahren.

  • Ist mir in der Tat noch nicht aufgefallen, danke für den Hinweis. Was ich wohl schon nutze gegen eingebundene Videos:

    https://greasyfork.org/en/scripts/370-stop-overzealous-embedding

    Das betrifft aber nicht Videos via HTML5. Alles nur eine Frage der Zeit.

  • Der Fission-Meilenstein M6b hat auch nur noch fünf offene Tickets für das Fission-Experiment (standardmäßige Aktivierung für einen Teil der Nightly-Nutzer), 110 offene Tickets für M6c (Nightly) und 218 offene Tickets für M7 (Beta-Experiment). Es geht vorwärts.


    Der Meilenstein M6b ist nun abgeschlossen, womit Firefox bereit für das Fission-Experiment ist. Noch 92 offene Tickets für M6c und 224 offene Tickets für M7 (Beta-Experiment).


    In dem Zusammenhang möchte ich nochmal auf about:processes hinweisen, was in den letzten Wochen einige Verbesserungen erhalten hat

  • Wenn das aktuelle Modell soweit "rund" ist, was ist dann der weitere Plan? Wird die Site Isolation dann wie bei Chromium noch weiter verfeinert oder soll es erstmal auf der Stufe bleiben?


    Für Fenix ist das noch nicht absehbar, oder? Das letzte Mal als ich nachschaute hat Fenix immer noch nur einen Web Content-Prozess genutzt, also ist noch nicht mal e10s dort aktiv.

  • Bis auf Frame-Ebene ist ja schon ziemlich fein unterteilt. Wie würdest du das noch weiter verfeinerrn beziehungsweise was macht Chromium darüber hinaus?


    e10s-multi und Fission sind definitiv ein Thema für Fenix, aber wenn du "absehbar" auf die nächsten paar Monate beziehst, würde ich das als sehr unwahrscheinlich einschätzen. Aber dass ein Ticket eröffnet worden ist, um e10s-multi in der Nightly-Version zu aktivieren, ist jetzt auch gerade mal drei Monate her (https://bugzilla.mozilla.org/show_bug.cgi?id=1654817), was zwar nicht heißt, dass eine Auslieferung nahe wäre, aber zumindest dafür spricht, dass das Thema noch aktuell ist. Und aktive Arbeit findet auch statt wie zum Beispiel in https://bugzilla.mozilla.org/show_bug.cgi?id=1668376, die Tage erst behoben.

  • Für Chromium gibt es hier den aktuellen Stand: https://www.chromium.org/devel…olation#TOC-Project-Tasks


    Für Firefox habe ich leider nichts ähnlich detailliertes und nach außen verständliches gefunden. Ein großer Unterschied ist meines Wissens, dass Firefox alle Seiten eines Origins in einen Prozess packt, während Chromium zumindest bei genügend RAM möglichst auch gleiche Origins in einzelne Prozesse packt.


    Wobei man da mittlerweile auch in Limits zu laufen scheint, insbesondere RAM-Verbrauch und zu viel IPC-Overhead durch die hohe Prozessanzahl. Unter Android ist die Site Isolation auch deutlich zurückgefahren, aber immerhin vorhanden.


    Wobei Fenix da noch größere Probleme zu haben scheint, mir zerschießt es momentan gerne öfter mal den Web-Prozess, was sich dann zB darin äußert, dass die Tastatur in Fenix kaputt ist. Mozilla ist das wohl bekannt, aber man scheint da noch keine wirklich gute Lösung zu haben.