Ein neuer Artikel wurde veröffentlicht:
ZitatMozilla hat Version 2.39 seiner VPN-Clients für das Mozilla VPN veröffentlicht.
Ein neuer Artikel wurde veröffentlicht:
ZitatMozilla hat Version 2.39 seiner VPN-Clients für das Mozilla VPN veröffentlicht.
Hallo,
was sagt denn der eBay-Support zur Unterstützung einer mehr als drei Jahre (!) alten Firefox-Version? Ausschlaggebend für Webkompatibilität ist nicht das Datum des letzten Sicherheits-Updates, sondern das Erscheinungsdatum des jeweiligen Major-Releases. Deswegen gilt auch Firefox ESR 115.38 in diesem Sinne als über drei Jahre alt.
PS: Vor wenigen Tagen hattest du noch Probleme mit WhatsApp, nicht lange davor hast du hier ein Thema auf Grund von Problemen auf anderen von dir nicht genannten Websites eröffnet. Probleme dieser Art werden zwangsläufig immer weiter zunehmen. Aktualisiere doch jetzt endlich mal dein System … 🤦♂️ Zumal die damals von dir genannten Gründe, wieso du immer noch Windows 7 nutzt, ja schon nicht glaubhaft waren, weil sämtliche von dir genannten Anwendungen auch auf neueren Windows-Versionen laufen …
Ein neuer Artikel wurde veröffentlicht:
ZitatMozilla hat Firefox 153 für Apple iOS veröffentlicht. Dieser Artikel beschreibt die Neuerungen von Firefox 153.
Artikel lesen: „Mozilla veröffentlicht Firefox 153 für Apple iOS mit KI-Assistent in den USA“
Das war auch nur eine Theorie. Am Ende können sowieso auch mehrere Faktoren in Kombination ausschlaggebend sein, wieso ein Profil langsamer als ein anderes ist und deswegen vielleicht in dem einen Profil etwas geloggt wird, in den anderen nicht.
ich hatte solche Dateien noch nie in meinem Profilordner, zumindest sind sie mir noch nie aufgefallen. Auch jetzt erst auf Grund der Menge.
Nach meinem Verständnis geht es dabei um das Logging von „Main-Thread I/O”, d.h. die Ausführung ressourcenintensiver Ein- und Ausgabevorgänge auf dem primären UI-Thread, was ein Problem für die Performance ist. Ich könnte mir vorstellen, dass sich dahingehend ein Firefox-Profil anders verhält als ein anderes, insbesondere wenn es durch nicht auf Performance optimierte Scripts erweitert wurde. ![]()
Ich habe hier mal alles aktiviert:
Sollte das nicht sowieso der Fall sein? ![]()
Die Dateien sollten automatisch gelöscht werden, wenn Telemetrie aktiviert ist. Siehe Kommentar im Quellcode:
Zitat// Note: These files should be deleted by telemetry once it reads them. If
// there were no telemetry runs by the time we shut down, we just add files
// to the existing ones instead of replacing them. Given that each of these
// files is a bug to be fixed, that is probably the right thing to do.
Hinweis: Es handelt sich dabei um nichts Neues. Der entsprechende Code, der diese Dateien erstellt, wurde vor knapp 13 Jahren in Firefox 29 hinzugefügt.
loadSubScript oder loadSubScriptWithOptions werden aktuell vier Mal verteilt auf drei verschiedene Dateien verwendet. Ich habe einfach nur im Ordner nach loadSubScript gesucht.
Services.scriptloader.loadSubScript(mainFileURI, this, 'UTF-8');
Services.scriptloader.loadSubScript(this.utilFileURI, window, "UTF-8");
Services.scriptloader.loadSubScript(this.ucFileURI, window, "UTF-8");
Components.classes["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Components.interfaces.mozIJSSubScriptLoader)
.loadSubScriptWithOptions(userChrome.getURLSpecFromActualFile(aFile), {
target: window,
charset: userChrome.charSet,
ignoreCache: userChrome.ignoreCache
});
=>
Services.scriptloader.loadSubScriptWithOptions(mainFileURI, {
target: this,
charset: 'UTF-8',
allowUnsafeURL: true
});
Services.scriptloader.loadSubScriptWithOptions(this.utilFileURI, {
target: window,
charset: 'UTF-8',
allowUnsafeURL: true
});
Services.scriptloader.loadSubScriptWithOptions(this.ucFileURI, {
target: window,
charset: 'UTF-8',
allowUnsafeURL: true
});
Components.classes["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Components.interfaces.mozIJSSubScriptLoader)
.loadSubScriptWithOptions(userChrome.getURLSpecFromActualFile(aFile), {
target: window,
charset: userChrome.charSet,
ignoreCache: userChrome.ignoreCache,
allowUnsafeURL: true
});
Alles anzeigen
Natürlich ist das möglich. Du kannst Farben in jeder von der Webplattform unterstützten Weise schreiben.
Bedeutet, der Eintrag bleibt dauerhaft erhalten?
Nein. Das steht explizit im Code kommentiert, dass diese Option nur temporär ist. Dass jeder Script-Nutzer eine Option in about:config verändert, ist aber auch nicht notwendig, wenn der ScriptLoader aktualisiert wird.
Es liegt meiner Meinung nach am import Pfad.
Wie müsste man den ändern?
Damit hat das nichts zu tun. Aufrufe dieser Art müssen ersetzt werden:
// alt
Services.scriptloader.loadSubScript(this.utilFileURI, window, "UTF-8");
// neu
Services.scriptloader.loadSubScriptWithOptions(this.utilFileURI, {
target: window,
charset: 'UTF-8',
allowUnsafeURL: true
});
Man kann es auch schöner lösen, womit man allowUnsafeURL nicht benötigt. Aber das ist der einfache Fix, der den alten Zustand wiederherstellt und den Mozilla selbst in seinen automatisierten Tests verwendet. In deinem Loader sehe ich vier Stellen, in denen allowUnsafeURL zu ergänzen wäre.
Sören Hentzschel Was soll man darunter verstehen? Wird die Funktionsweise von Scripts, wie wir sie kennen, abgeschafft, bzw. ist sie auf Dauer nur noch mit dem Config-Schalter möglich? Bleibt dieser erhalten? Fragen über Fragen....
Die standardmäßige Sicherheit von Firefox wird weiter erhöht, weil ja auch die Bedrohnungen immer größer werden, weswegen das sinnvoll ist. Wer Scripts nutzt, nimmt ja bereits in Kauf, die Sicherheit potenziell zu reduzieren. Das ist weiterhin möglich.
Wer einen Scriptloader nutzt, der nicht kompatibel mit dieser Änderung ist, und auf einen Eingriff in about:config verzichten möchte, muss auf eine Aktualisierung des genutztes Scriptloaders warten. Das sieht für mich nach einer recht simplen Anpassung aus, um wieder den gleichen Zustand wie vorher zu erhalten.
Mit aktivierter Titelleiste (nur dann) kann man standardmäßig zumindest per Doppelklick in die Tableiste einen neuen Tab öffnen.
Geplant ist, dass die durchgeführte Änderung auch noch in Firefox ESR 153 Einzug erhalten wird.
Das weiss ich nicht.
Dann gib doch auch nicht solche Tipps. Dateien zu entfernen darf nie eine Lösung sein, die man einfach so in den Raum wirft, ohne die Auswirkungen verstanden zu haben. Und ehrlich gesagt frage ich mich, wie du überhaupt auf so etwas gekommen bist, wenn du gar nicht weißt, was diese Dateien machen.
Meine angepasste FFX-Version (DNS-over-HTTPS, Hyper-V etc.) startet schneller und lädt Seiten "geschmeidiger"
Mindestens der Zusammenhang mit DoH ergibt keinen Sinn. Ob ein Performance-Unterschied überhaupt wahrnehmbar ist, sei mal dahingestellt (sehr wahrscheinlich nicht). Aber wenn, dann bringt dir DoH eine Verzögerung und keine Beschleunigung, auf Grund des zusätzlichen TLS-Handshake-Overheads. Das Argument für DoH ist nicht Performance.
Individuelle Designanpassungen werden alle übernommen. Mit diesen drei Dateien nicht - warum auch immer?
Das fällt mir zwar sehr schwer zu glauben, insbesondere da es sich um Windows-spezifische Dateien handelt, das Firefox-Design aber zum allergrößten Teil plattformunabhängig ist. Aber selbst, wenn dem so sein sollte, dann gibt es mindestens einen anderen Weg, das gleiche Ziel zu erreichen, ohne Dateien zu entfernen …
PS: Wenn man Firefox schon abkürzen muss, dann ist Fx die offizielle und damit korrekte Abkürzung.
Ein neuer Artikel wurde veröffentlicht:
ZitatMozilla hat mit Firefox 153.0.1 sein wöchentliches Korrektur-Update veröffentlicht. Dieser Artikel beschreibt die Änderungen des neuesten Updates.
Ich spende dafür regelmäßig an Mozilla.
Das ist sehr großzügig. Ich möchte in diesem Zusammenhang aber darauf hinweisen, dass du entweder für die Mozilla Foundation oder die MZLA Technologies Corporation spendest, wenn du für „Mozilla” spendest. Beide haben nichts mit der Firefox-Entwicklung zu tun. Dementsprechend ist für mich unklar, was damit in Bezug auf dieses Firefox-Thema ausgesagt werden soll.
150.0 = ok; 153.0.1 = URL Fehler
Wenn das für dich verlässlich reproduzierbar ist, wäre eine Eingrenzung mittels mozregression sehr zielführend, um den Auslöser und damit letztlich eine Lösung zu finden oder zumindest eine hilfreiche Meldung für Mozilla erstellen zu können:
Das frage ich mich auch, denn das kann in diesem Fall ja nicht einmal nur eine nicht freigegebene Version vom Mozilla-Server sein, wie es sonst der „Klassiker” ist. Von Mozilla existierte zu dem Zeitpunkt schlicht und ergreifend noch gar kein Build von Firefox 153.0.1. Zu dem Zeitpunkt war noch nicht einmal auch nur ein einziger Patch für Firefox 153.0.1 gelandet …
Was auch immer „ältere Einstellungen” in diesem Kontext sowie „wegzippen” bedeuten soll – wenn du die Suchmaschine deiner Wahl bemühst, wofür diese Dateien sind, wirst du hoffentlich selbst drauf kommen, dass es wohl eher keine so zielführende Idee sein wird, daran herumzupfuschen. Schon gar nicht für eine kosmetische Anpassung, die man ja auch so problemlos erreichen kann …
Dass es am 24.7. noch keinen Firefox 153.0.1 gab, ist halt eine Tatsache und kann dementsprechend nichts sein, worüber man eine „Meinung” haben könnte …
Ein neuer Artikel wurde veröffentlicht:
ZitatMozilla hat Firefox 153 für Android veröffentlicht. Dieser Artikel beschreibt die Neuerungen von Firefox 153 für Android.
Artikel lesen: „Mozilla veröffentlicht Firefox 153 für Android“