Der genannte Menüeintrag befindet sich im Anwendungsmenü, im Lesezeichen-Menü sowie in der Menüleiste. An allen Stellen über einen gewöhnlichen Linksklick erreichbar, da ist kein Kontextmenü involviert. Ich weiß auch nicht, was es dem Themenstarter helfen sollte, einen Menü-Eintrag anders zu positionieren.
Beiträge von Sören Hentzschel
-
-
Die beiden Links in Beitrag #2 entsprechen nicht genau dem Wunsch des Themenstarters. In beiden Fällen wird davon ausgegangen, dass man die Bibliothek aus der Sidebar heraus öffnen möchte. Beim Themenstarter geht es ausdrücklich um das direkte Öffnen der Bibliotek.
Technisch umsetzbar wäre das vermutlich nur über ein User-Script, welches die entsprechende interne Firefox-Funktion überschreibt. Aber ob so etwas bereits existiert, weiß ich nicht.
-
Hallo,
der hier dargestellte Zusammenhang ist schlicht und ergreifend nicht möglich. Die Synchronisation betrifft keine geöffneten Tabs und schon gar nicht komplette Fenster. Selbst eine Synchronisation von Tabs bedeutet lediglich, dass die Tabs anderer Geräte über eine Sidebar, das Synchronisations-Menü sowie Firefox View zugänglich gemacht werden. Aber niemals werden dadurch automatisch Tabs auf anderen Geräten geöffnet oder geschlossen. Eine solche Funktionsweise existiert in Firefox überhaupt nicht. Und wenn die Synchronsiation von Tabs nicht einmal aktiviert war, wie gesagt wurde, dann kann dieser Zusammenhang ja gleich doppelt nicht stimmen.
PS: Wann gedenkst du, dein Betriebssystem zu aktualisieren, welches seit Jahren keine Sicherheits-Updates mehr erhält? Die Unterstützung für Firefox auf Windows 7 wird auch sehr bald eingestellt werden.
-
Hallo,
so etwas wie eine Lesezeichensymbolleiste gibt es in Firefox für Android nicht.
-
Was fehlt denn, wenn FF kein JS kann?
Ich kann mir höchstens vorstellen, dass Mira_Belle damit die Script-Vorbereitungen meint, damit du Scripts ausführen kannst. Aber wenn du auch andere Scripts nutzt, ist das nicht das Problem.
-
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.
-
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.
-
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.
-
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.
-
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.
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.
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?
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:
-
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.
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.
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“.
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,
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:
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.
-
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.
