Beiträge von Sören Hentzschel

Hallo,

das hat mit Firefox überhaupt nichts zu tun, die Seite merkt sich das schlicht und ergreifend nicht. Chrome und Safari zeigen das identische Verhalten.

Zitat von Mitleser

eine andere Art der Einbindung von --menuitem-icon in Zeile 59

Aber wieso? Das ist doch komplett inkonsistent zum restlichen Code ist. Direkt eine Zeile darunter greifst du ja auch auf die style-Eigenschaft zu. Und eine Zeile darüber auf die classList-Eigenschaft. Da verwendest du ja auch nicht setAttribute('class', '…'). Zumal du dir damit auch Flexibilität nimmst. Du kannst beliebig viele Zeilen schreiben, in denen du auf die style-Eigenschaft zugreifst. Aber setAttribute('style', '…') kannst du genau ein einziges Mal verwenden, sonst überschreibst du dir alles wieder. Und übersichtlicher ist die Verwendung von setProperty für Variablen auch, da Variablen-Name und -Wert damit getrennt voneinander sind. Also ich sehe keinen Vorteil in dieser anderen Art.

bege Jemand müsste einen Fehlerbericht bei Mozilla erstellen. Insgesamt 21 Abstürze von nur elf verschiedenen Installationen in den letzten sieben Tagen sind schon echt nicht viel. Der Absturz taucht damit nicht in den Top-Listen von Mozilla auf und wird es ohne Meldung vermutlich schwierig haben, Beachtung zu finden.

.DeJaVu Absturz-IDs wurden bereits genannt, Beitrag #3.

Zitat von 2002Andreas

Zitat von FuchsFan

Das funktioniert hier auch ohne.

Hier nicht, dann ist das Icon weg

Anführungszeichen sind optional, solange es im Wert kein Leerzeichen gibt. In deinem Beispiel kommt ein Leerzeichen vor, daher brauchst du die Anführungszeichen. FuchsFan braucht sie nicht, weil bei ihm kein Leerzeichen vorkommt. Wenn man sicher gehen möchte, setzt man einfach immer welche.

Die letzte Aussage versuchte ich mit dem zitierten Text klarzustellen. Das ist nicht der Fall. Es geht ausschließlich um menuitem-Elemente. Bei Elementen, für die list-style-image eine gültige CSS-Eigenschaft ist, gibt es keinen Grund, etwas zu ändern.

Und eben, weil das Problem noch auftritt, sollst du mozregression nutzen und mit Firefox 140 als letzte funktionierende und Firefox 141 als erste defekte Version testen.

Zitat von 2002Andreas

list-style-image wurde entfernt.

Damit hier kein Missverständnis entsteht: Die CSS-Eigenschaft list-style-image gibt es nach wie vor. Aber der Grafik-Part des menuitem-Elements ist jetzt HTML und kein XUL mehr und das img-Element von HTML hat noch nie list-style-image unterstützt.

So, wie grisu2099 es über eine CSS-Variable gelöst hat, ist der Weg, den auch Firefox an Stellen nutzt, an denen vorher list-style-image verwendet worden ist.

Zitat von Fuzzifux

Das erwartete Standartverhalten war, das das selbstdefinierte Verzeichnis benutzt wird!

Erwartetes Standardverhalten bedeutet: Firefox verhält sich so, wie es implementiert wurde, es liegt also kein Fehler vor.

Abgesehen davon: Die sichtbare Einstellung, von der du schreibst, bezieht sich ausdrücklich auf Downloads, nicht auf Screenshots. Du hast vorher kein Screenshot-Verzeichnis definiert. Das war vor Firefox 141 überhaupt nicht möglich. Die Screenshots landeten vorher halt zufällig im konfigurierten Download-Verzeichnis. Dass das eine das andere nicht automatisch einschließt, siehst du an Windows, was du nach eigener Angabe nutzt: Dort gibt es einen eigenen Screenshot-Ordner, der nicht der Downloads-Ordner ist. Firefox hätte die Screenshots vorher auch einfach dort ablegen können. Das hättest du vor Firefox 141 dann nicht ändern können. Das haben sich auch manche Firefox-Nutzer gewünscht. Deswegen wurde diese Option eingeführt. Jetzt kann jeder das Verzeichnis nutzen, welches er oder sie möchte, unabhängig von der Konfiguration für Downloads.

Zitat von Fuzzifux

und nun muss ich in den Untiefen des Programms rumwerkeln um es wieder gangbar zu machen :-((

Das klingt sehr dramatisch. Die Anpassung in about:config sollte relativ schnell erledigt sein. Und bei Problemen fragst du hier einfach nach.

Zitat von Fuzzifux

Das ist definitiv NICHT in Ordnung!

Die Aussage kann ich nicht nachvollziehen. Mozilla ist der Entwickler der Software. Selbstverständlich dürfen sie die Standard-Orte so festlegen, wie sie wollen. Wieso sollte das nicht in Ordnung sein?

Und nochmal: Mozilla hat dem Nutzer eine neue Option zur Anpassung gegeben, die es vorher nicht gab. Also worüber reden wir hier? Sind mehr Anpassungsoptionen für den Nutzer jetzt wirklich auch schon falsch?

Zitat von Fuzzifux

Wenn es wenigstens unter "Neue Funktionen und Änderungen" beschrieben worden wäre, aber da steht auch nichts drin.

Die Release Notes erwähnen bewusst nicht jede Kleinigkeit und neue Option. Für deutlich mehr Umfang (was dafür halt ehrlicherweise auch deutlich weniger Menschen lesen, weil es zu viel ist) liest du am besten regelmäßig die Artikel hier auf camp-firefox.de.

Das dürfte einige Anpassungen betreffen: #urlbar-background (ID) ist jetzt .urlbar-background (Klasse).

Hallo,

wenn das Problem reproduzierbar in Firefox 141, aber nicht in Firefox 140 auftritt, nutze bitte mozregression und teile die letzte Pushlog-URL mit uns:

mozregression

Zitat von PrismAccessTerminal

Aus einem Schritt wurden drei und das bei einer Funktion

Du hast dich verzählt. Es wurde ein Schritt mehr, nicht zwei. Auch ohne „Scotch Bonnet“ musst du nach der Auswahl der Suchmaschine noch Enter drücken, was du in deiner Beschreibung unterschlagen hast. Und wählst du zuerst die Suchmaschine aus (was ich für die logischere Reihenfolge halte), ist die Anzahl mit und ohne „Scotch Bonnet“ sogar identisch.

Aber du hast ja jetzt selbst herausgefunden, dass es mit gedrückter Shift-Taste auch bei der nachträglichen Suchmaschinen-Auswahl bei der gleichen Anzahl an Klicks bleibt.

Zitat von PrismAccessTerminal

Form follow function ist scheinbar nicht mehr gewollt.

Den Spruch hast du bei deinem letzten Thema vor fünf Jahren schon gebracht, wo die Aussage überhaupt nicht gepasst hatte. In diesem Fall solltest du zumindest einen Blick über den eigenen Tellerrand wagen: Ich verstehe, dass es für dich ein Klick mehr ist, den du dir gerne sparen würdest. Aber diese Änderung wurde mit der Begründung umgesetzt, dass es „Benutzern erleichtert, zwischen Suchmodi zu wechseln und einmalige Suchvorgänge durchzuführen“. Worauf das begründet ist, weiß ich auch nicht. Aber Mozilla betreibt auch viel Nutzerforschung und Marktanalyse. Möglicherweise war die alte Darstellung für einen nicht unerheblichen Teil der Nutzer irritierend / missverständlich. Solche Aspekte sollte man auch berücksichtigen, bevor man unterstellt, Mozilla würde Dinge nur der Optik wegen ändern. So arbeitet Mozilla nicht. Natürlich kannst du es mit keiner Entscheidung allen Menschen recht machen. Irgendwo wird man bei einem Produkt für die Massen, was Firefox nun einmal ist, immer Kompromisse eingehen müssen. Im Zweifel muss Massentauglichkeit logischerweise höher als Nischen-Nutzung gewichtet werden, wenn Firefox erfolgreich sein soll.

Übrigens: Die separate Suchleiste wird demnächst die gleiche Änderung erhalten.

Zitat von PrismAccessTerminal

Was ändert browser.urlbar.scotchBonnet.enableOverride denn noch?

Neuer Suchmaschinen-Button in Adressleiste, Suchbegriffe in der Adressleiste, kontextbasierter Suchmodus, neue Schlüsselwörter für die Adressleiste, Action-Buttons für die Adressleiste, die Hervorhebung des unsicheren statt des sicheren Protokolls in der Adressleiste. Das alles hängt an „Scotch Bonnet“.

Zitat von lenny2

v137+ calculations local weather

Das hingegen hat beides nichts mit „Scotch Bonnet“ zu tun.

Zwei sehr relevante Informationen in Zusammenhang mit dieser Option fehlen: 1. Diese Option schaltet weit mehr um als nur das, wonach gefragt wurde. 2. Diese Option wird mittelfristig aus Firefox verschwinden, da es sich nur um eine temporäre Option für die Entwicklung und Ausrollung handelt. Daher würde ich eher dazu raten, sich daran zu gewöhnen, dass es jetzt eben etwas anders aussieht.

Die Funktionsweise von Bugzilla hat sich in den letzten 20 Jahren nicht grundlegend verändert. Für die Standard-Suche von Bugzilla muss man halt wirklich die Begriffe exakt so schreiben, wie sie im Titel vorkommen. Ungefähre Formulierungen funktionieren genauso wenig wie ein Durchsuchen von Beschreibungen und Kommentaren. Das kann es schwierig machen, Dinge zu finden. Manchmal ist es einfacher, sich durch die Liste offener Tickets einer Komponente (in dem Fall Firefox: Sidebar) nach Datum sortiert zu lesen, die erweiterte Bugzilla-Suche oder sogar die Suche über Google zu verwenden.

Hallo,

Zitat von Fuzzifux

Wenn Sie auf die Schaltfläche „Herunterladen“ klicken, wird das Bild unter C:\Benutzer\<Benutzername>\Downloads gespeichert.

Nach dem Upgrade auf 141.0 wird es nun immer unter „C:\Users\<Benutzername>\Downloads” gespeichert und nicht im vom Benutzer konfigurierten Download-Verzeichnis.

Das ist doch beides das gleiche Verzeichnis, bloß einmal in der deutschsprachigen und einmal in der englischsprachigen Schreibweise?

Dass das Downloads-Verzeichnis genutzt wird, ist das erwartete Standardverhalten. Siehe Artikel auf unserer Website zu Firefox 141:

Zitat von camp-firefox.de

Mit browser.screenshots.folderList gibt es einen weiteren neuen Schalter in about:config, der den Speicherort für Screenshots betrifft. Wird dieser auf 0 gesetzt, werden Screenshots auf dem Desktop gespeichert. Bei einem Wert von 1 (Standard), wird der Downloads-Ordner des Systems genutzt. Wird der Schalter auf 2 gesetzt, kann die Option browser.screenshots.dir genutzt werden, um einen Ordner festzulegen. Und bei einem Wert von 3 wird der Screenshot-Ordner des Systems genutzt.

Ergänzend: In Firefox 143 wird es noch 4 als möglichen Wert geben. Dann wird die Download-Einstellung von Firefox für Screenshots verwendet.

Zitat von grisu2099

Hier funktioniert es...

Ob es trotzdem funktioniert, weil CSS tolerant ist, habe ich nicht getestet, aber du hast die Anführungszeichen falsch gesetzt. Das wäre dann trotzdem gut zu korrigieren. Und du verwendest in deinem Code eine nicht definierte Variable „css“, was in jedem Fall einen Fehler in der Konsole werfen muss.

Zitat von 2002Andreas

Danke dafür, funktioniert leider noch nicht.

Ich hatte den url()-Teil versehentlich entfernt, den ich in der CSS-Variante selbst noch drin hatte. Im letzten Beitrag steht es jetzt eh schon richtig, aber ich habe mein Beispiel auch noch korrigiert, damit da nichts Falsches mehr steht.

Eine CSS-Variable über JS zu setzen, funktioniert so:

menuitem.style.setProperty('--menuitem-icon', 'url(chrome://browser/skin/downloads/downloads.svg)');

Das kann natürlich nur funktionieren, wenn das Script für den neu hinzugefügten Menüpunkt genau die Erwartungen erfüllt, die Firefox voraussetzt, damit das Icon dann verwendet wird. Das konnte ich noch nicht im Detail prüfen. Es kann wie gesagt sein, dass noch mehr anzupassen ist, damit das auf diesem Weg klappt.

Nachtrag: Fehlendes url() ergänzt.

Zitat von phantomjunior

gibt es einen offiziellen Support für den Mozilla Firefox? Hast du eine E-Mail-Adresse?

Support zu Firefox erfolgt auf ehrenamtlicher Basis in Foren wie diesem hier. Individueller Support per E-Mail für ein kostenloses Produkt mit über 200 Millionen Nutzern weltweit wäre für eine Organisation wie Mozilla kaum finanzierbar.

Wenn du das Ganze für einen Fehler in Firefox hältst, könntest du einen entsprechenden Fehlerbericht (in englischer Sprache) erstellen:

Bugzilla Main Page

bugzilla.mozilla.org

Zitat von 2002Andreas

evtl. hat Sören ja eine Erklärung dafür

Es wird für menuitem-Elemente jetzt das img-Element nach dem HTML-Standard und nicht mehr aus XUL verwendet. Und für das funktioniert die CSS-Eigenschaft list-style-image nicht. Es gibt aber eine CSS-Variable, die man nutzen kann, zum Beispiel:

#context-to-top {
  --menuitem-icon: url('chrome://browser/skin/downloads/downloads.svg');
};

Siehe:

Ob noch zusätzliche Anpassungen notwendig sind, kann ich aktuell nicht testen.

Hallo,

dass sich Firefox die Sortierung merkt, soll in der neuen Sidebar noch implementiert werden, bevor die alte Sidebar entfernt wird.

Siehe:

Bis dahin kannst du wieder die alte Sidebar aktivieren, indem du die entsprechende Sidebar-Checkbox in den Firefox-Einstellungen deaktivierst: