Teste bitte mal diesen Code:
Der Code funktioniert nicht, dann wird gar kein Lautsprecher Symbol mehr angezeigt.
Aber ich denke ich lass es so wie es jetzt ist, des Symbol hat wieder seine gewohnte Größe, das ist die Hauptsache 
Vielen Dank für die Hilfe.
Hallo Andreas,
Danke schon mal, sieht wieder fast so aus wie vorher die Größe habe ich jetzt auf 1.5 gestellt. Mit der schwarzen Farbe kann ich leben.
.tab-audio-button {
fill: blue !important;
transform: scale(1.5, 1.5) !important;
background-color: transparent !important;
border: none !important;
}
Was noch ein bisschen falsch aussieht, ist der hover Hintergrund
Der ist größer als der Tab. Das liegt wahrscheinlich daran, dass das Lautsprecher Symbol so einen Kreis außen herum bekommen hat, welchen ich transparent geschaltet habe. Vielleicht lässt sich der hover Hintergrund auch komplett deaktivieren.
Notfalls könnte ich auch damit leben wie es jetzt ist.
Gruß,
Armin
Hallo,
Ich hatte das Lautsprecher Symbol im Tab angepasst, weil es zu klein war:
/*** Tab Lautsprecher Symbol grösser ***/
.tab-icon-overlay {
fill: blue !important;
transform: scale(2.0, 2.0) !important;
background-color: transparent !important;
border: none !important;
}Leider hat Mozilla das mit der 136 geändert:
.tab-audio-button {
#tabbrowser-tabs:is([orient="vertical"][expanded], [orient="horizontal"]) &:not([pinned]):not([crashed]) {
&[soundplaying]::part(button) {
background-image: url("chrome://browser/skin/tabbrowser/tab-audio-playing-small.svg");
}
}
}Wie könnte ich das hinbekommen,dass es wieder aussieht wie vorher?
Ich habe schon versucht so was wie tab-audio-playing-medium.svg
Aber das existiert so nicht.
Wie kann ich herausbekommen, wie die anderen Größen bezeichnet sind?
Gruß,
Armin
Ich hatte dieses Verhalten auch seit dem Update auf 133. Ich benutze eine userChrome.css. Ich hatte dann gleich den Verdacht, dass es an einer meiner css Einstellungen liegt und habe 2 verdächtige Einstellungen auskommentiert.
#urlbar[breakout][breakout-extend] {
/*left: 0 !important;*/
/*width: 100% !important;*/
}Das war wohl in früheren Versionen erforderlich, seit der Version 133 führt es dazu, dass die Adresszeile die ganze Breite des Fensters einnimmt. Jetzt passt die Breite und die Position wieder.
Oh Mann ich hatte das tatsächlich in die userchrome.css reingeschrieben 
/*** Privater Modus ***/
#main-window[privatebrowsingmode=temporary] .tabbrowser-tab[selected] {
color: black !important;
}
#main-window[privatebrowsingmode=temporary] tooltip {
color: black !important;
}Ich erinnere mich jetzt auch wieder, ich hatte mal vor langer zeit auf ein Theme gewechselt, wo die Schrift in den Tooltips hell auf einem hellen Hintergrund war. Und da habe ich das in der userChrome korrigiert. Jetzt habe ich ein Theme, wo die Tooltips einen dunklen Hintergrund haben und dann passt diese Einstellung natürlich nicht mehr. Da habe ich mich nicht mehr daran erinnert, ist schon zu lange her.
Also Thema erledigt, vielen Dank für die Unterstützung.
Ja, ich nutze eine userChrome.css
Hallo Andreas,
Ja, ich habe gerade festgestellt, im Fehlerbehebungsmodus taucht der Fehler nicht auf. Dann liegt es wohl an einer meiner Einstellungen.
Da werde ich mich dann mal auf die Suche machen.....
Ich habe jetzt in der Arbeit mal nachgesehen, der Fehler ist auch unter Windows11 vorhanden. Es ist also doch ein allgemeiner Fehler im Firefox und hängt nicht mit meiner Xfce Umgebung zusammen.
Es ist schon ein helles Theme (Qogir-Light) aber die Tooltips haben einen dunklen Hintergrund mit einer weißen Schrift.
Ich wusste gar nicht, dass eine Anwendung deren Aussehen beeinflussen kann. Eine Erweiterung die automatisch zwischen dark und light wechselt verwende ich nicht.
Ist eigentlich auch nicht so tragisch, es ist mir heute nur mal wieder aufgefallen, als ich ein Formular in einer Webanwendung getestet habe, wo ich Tooltips eingebaut habe.
Interessant ist, wenn ich den Privatmode auf dark lasse, werden manche Tooltips mit einem hellen Hintergrund dargestellt.
Aber möglicherweise ist das gar kein Firefox Problem, sondern taucht halt jetzt nur in meiner Umgebung auf.
Hallo,
Ich habe den privaten Modus vom Firefox auf hell gestellt.
Jetzt werden im privaten Modus manche Tooltips mit dunklem Hintergrund und weißer Schrift, manche Tooltips aber mit dunklem Hintergrund und schwarzer schrift dargestellt. Hier mal z.B. home und reload:
Auf Webseiten wird immer die dunkle Schrift angezeigt:
Weiß jemand ob sich das fixen lässt? Das Problem taucht nur im privaten Modus auf.
Gruß,
Armin
Ich habe es herausgefunden, ich muss das "@media" Element einfach nur weglassen, dann funktioniert es.
.menupopup-arrowscrollbox {
border-radius: 0 !important;
}
menu, menuitem, menucaption {
appearance: none !important;
border-radius: 0 !important;
}Funktioniert leider nicht.
Die Menüs, welche jetzt abgerundet wurden, die werden zumindest was die Farbe des ausgewählten Items angeht vom Betriebssystem gesteuert. Weil dieses Blau habe ich überall in den Menüs von meinem Xfce Desktop. Die Menüs in der Menüleiste sind also auch betroffen. Deswegen kann ich die vermutlich im Firefox nicht umstellen. Die Abrundung lässt sich aber rückgängig machen. Die Einstellung wird in der menu.css gemacht. Diese Datei finde ich aber nicht in meinem Profil. In der Toolbox lässt sich das umstellen.
Hallo,
Mit dem letzten Update ist das Kontextmenü abgerundet worden.
Das Menü selber habe ich schon wieder gerade bekommen, mit dieser Einstellung:
.menupopup-arrowscrollbox {
border-radius: 0 !important;
}Das ausgewählte Menüitem wird aber auch noch abgerundet dargestellt. In der Browser Toolbox konnte ich das bereits korrigieren.
@media (-moz-gtk-non-native-menus) {
menu,
menuitem,
menucaption {
appearance: none;
border-radius: 4px;
}
}Wenn ich da den border-radius auf 0 setze, wird es eckig. Allerdings funktioniert das so nicht in der userChrome.css.
Wie muss ich das in die userChrome.css reinschreiben? Ich würde auch gerne noch die Farbe von dem ausgewählten Menüitem von jetzt blau auf ein grau ändern, weil es bei den anderen Menüs auch grau ist.
Gruß,
Armin
Mein letzter Beitrag war eigentlich nur zu Korrektur gedacht, weil meine Aussage dass der Dateiname random ist halt nicht zutrifft und ich wollte nicht dass da was falsches im Forum steht. Ich möchte halt bei so neuen Funktionen immer genau wissen wie es funktioniert, deshalb habe ich ja die ganzen Fragen hier gestellt, z.B. wo genau wird das Zeug konkret gespeichert usw.
Dann habe ich halt selber angefangen zu recherchieren und dachte mir, dass es möglicherweise auch für Andere interessant ist, deshalb meine vielen Beiträge zu diesem Thema. Also ich steigere mich da nicht rein, das ist einfach nur meine Neugierde und jetzt wo ich weiß wie es genau gemacht wird habe ich auch keine Bauchschmerzen damit. Es hat mich eben am Anfang wo ich noch nichts darüber wusste etwas getriggert.
Selbst wenn ich wüsste, wie ein Hash zu einem bestimmten Dateinamen auszusehen hätte, wüsste ich ja trotzdem nicht, ob diese Datei bei dir existiert, geschweige denn könnte ich darauf zugreifen.
social engineering ?
Aber jetzt habe ich glaube ich alles zu dem Thema herausgefunden deswegen schreibe ich jetzt auch nichts mehr dazu, versprochen
Da habe ich mich doch schon wieder getäuscht. Ich habe fälschlicherweise gedacht, dass der auf der Platte gespeicherte Dateiname (dieser 52 stellige String) random erzeugt wird. Jetzt habe ich jedoch festgestellt, dass der gleiche Dateiname (z.B. evilshit.sh) auch immer den gleichen String erzeugt. Ich habe das auf mehreren VMs getestet.
Der Dateiname:
evilshit.sh
erzeugt immer diesen String:
DKUOV7VWNAKRKAPT3M6RRIASSRYNLTWZH5P72VFYVKX2O74GS7DQ
Wenn ich jetzt noch die Profilbezeichnung von jemanden kenne – und die steht ja z.B. in den abbout:support Informationen, welche häufig zu Support Zwecken auch in Foren gepostet werden – Dann kann ich den gesamten Pfad meines Payloads rekonstruieren.
Wäre interessant, wenn das mal jemand bei sich ausprobiert ob das wirklich reproduzierbar ist. Der Inhalt der Datei spielt dabei keine Rolle, nur der Dateiname ist entscheidend.
Es sieht so als wäre das einfach nur eine Hashfunktion auf den Dateiname.
Sobald Mozilla die Mechaniken zur verschlüsselten Speicherung hat, können sie für OPFS darauf vermutlich aufbauen.
Bleibt zu hoffen, dass dies in Bälde gemacht wird, dann wäre dieses Problem gefixt. Wenn die Datei verschlüsselt abgespeichert würde, dann würde dies die Sicherheit erheblich erhöhen.
Nochmal eine kurze Ergänzung zu dem Thema.
Ich hatte jetzt noch ein wenig mehr Zeit zum Testen und habe mir einen Editor für Arme gebastelt um ein paar Tests mit OPFS zu machen.
Meine Aussage, dass mozilla die Dateien in die Sqlite Datenbank schreibt war nicht ganz richtig. Das war nur so, weil ich da nur leere Dateien erzeugt habe. Mit meinem Editor kann ich diese jetzt auch mit Text füllen und dann wird im gleichen Pfad in dem die Datenbank ist noch ein Unterverzeichnis mit einer Datei angelegt.
Der Dateiname wird random generiert und besteht aus 52 Stellen (Großbuchstaben und Zahlen). Diese Datei enthält im Klartext den exakten Inhalt, wie er von der Webanwendung geschrieben wurde. Diese Datei kann von der Webanwendung jedoch nicht ausführbar gemacht werden. In der Datenbank stehen nur die Metadaten. Nehmen wir an es würde ein Python Skript von einer Webseite abgelegt, dann könnte dieses niemals direkt von der Webanwendung ausgeführt werden. Der Besucher der Seite jedoch könnte die Datei theoretisch ausführen (was er natürlich nicht tun würde). Mit einfachen Worten, es ist kinderleicht mit Hilfe von OPFS einen payload zu platzieren, dieser kann jedoch nicht ausgeführt werden. Ein Angreifer müsste mich also durch social engineering dazu bringen, seinen payload auszuführen, was ihm aber schwer fallen dürfte, da er den Namen der Datei nicht kennt, da dieser ja random ist. Das ist meines Erachtens ausreichend sicher, jedoch wäre es noch besser, wenn die Dateien – wie ich zuerst angenommen habe – in der Datenbank wären. Jetzt liegen sie in der Tat in meinem lokalen Dateisystem.
mozilla legt im Profil unter storage/default/<domain> verschiede Unterverzeichnisse an:
ls für localstorage
idb für InexedDB
fs für OPFS
cache für Service-Worker Dateien
Damit habe ich eine gute Möglichkeit schnell herauszufinden, welche Domains die ich besucht habe Dateien via OPFS bei mir abgelegt haben:
armin@freedom:storage$ find -type d|grep "/fs"
./default/https+++v22018096896673253.goodsrv.de/fs
./default/https+++v22018096896673253.goodsrv.de/fs/UVSobald die Websitedaten für die entsprechende Domain gelöscht werden sind all diese Dateien weg.
Was auch noch interessant ist, im Privaten Modus wird OPFS oder IndexedDB nicht ausgeführt.
Mal abgesehen davon, dass ich keine Tipps zur Abschaltung von Webstandards gebe, weil es keinen Vorteil hat und potentiell Probleme verursacht, auf die man später nicht kommt, ist bei Webstandards sowieso immer davon auszugehen, dass der entsprechende Schalter in about:config nur temporär existiert.
Jetzt wo ich weiß wie es im Firefox umgesetzt ist, will ich ja nicht mehr deaktivieren.
Da habe ich mich mal wieder umsonst aufgeregt
Also ich habe es jetzt durch try and error herausgefunden. OPFS speichert unter
.mozilla/firefox<profil>/storage/default
Da wird eine sqlite Datenbank angelegt. Damit macht OPFS nichts anderes als localstorage nur mit dem Unterschied, dass localstorage Strings und Integers speichert, während OPFS BLOBs speichert.
Leider hat der Firefox in den Entwicklerwerkzeugen unter Webspeicher keinen Eintrag für OPFS. Es gibt aber ein externes Tool mit dem ich die sqlite Dateien analysieren kann.
Ich habe ein einfaches Testscript geschrieben, welches ein Verzeichnis erzeugt:
Wenn ich dann die erzeugte sqlite Datenbank analysiere, ist das erzeugte Verzeichnis als BLOB sichtbar:
Da ich jetzt weiß wie es funktioniert, kann ich auch beruhigt auf die 111 updaten.
Die Aussage dass in das lokale Dateisystem geschrieben wird hat mich halt ein wenig irritiert.
Der Thread kann also als erledigt markiert werden.
Viele Grüße,
Armin
Storing data in the OPFS is similar to storing data in any other browser-provided storage mechanism that's private to the origin of the page (for example the IndexedDB API). This means that files in the OPFS differ from files selected using a picker in the following ways:
Permission prompts are not required to access files in the OPFS.
Clearing data for the site deletes the OPFS.
The OPFS is subject to browser quota restrictions.
Laut dieser Aussage von mozilla, die ich gerade gefunden habe soll angeblich die gleiche Quota greifen die auch für die IndexedDB gilt, d.h. max 50% der Partition in welcher die IndexedDB gespeichert ist. Diese befindet sich unter ~/.mozilla/<profile>/storage. Ich würde aus dieser Aussage von Mozilla auch mutmaßen, dass OPFS im gleichen Pfad gespeichert wird. Genau geht das aber aus der Seite nicht hervor.
In addition, it defines an API that makes it possible for websites to get access to a file system directory without having to first prompt the user for access.
Ich muss also nicht vorher um Erlaubnis gefragt werden, sondern die Webapplikation kann einfach munter darauf los schreiben.
Other than files in the origin private file system, files written by this API are not subject
to storage quota. As such websites can fill up a users disk without being limited by
quota, which could leave a users device in a bad state (do note that even with storage that is
subject to storage quota it is still possible to fill up, or come close to filling up, a users
disk, since storage quota in general is not dependent on the amount of available disk
space).
Es existiert also nach der Offiziellen Vorgabe keine Quota für dieses Dateisystem.
The origin private file system is a storage endpoint whose identifier is "fileSystem", types are « "local" »,
and quota is null.
Das ist aber wie es aussieht kein offizielles W3 Dokument. Bei der W3 läuft das unter der Bezeichnung: File API
File API: Directories and System
Das ist aber schon ein älteres Dokument. Ich frage mich ohnehin, warum das so schlecht dokumentiert ist. Unter dem Begriff OPFS finde ich keinen englischen und auch keinen deutschen Wikipedia Eintrag, was bei offiziellen Webstandards aber eigentlich immer der Fall ist.
Die Frage ist auch wie hat mozilla dieses Dateisystem implementiert, gibt es da eine offizielle Dokumentation von mozilla wo ich das herauslesen könnte?
Bei allem was ich bisher darüber gelesen habe, möchte ich dieses feature auf jeden Fall abschalten, offizieller Webstandard hin oder her. Ich benutze keine Webapplikationen für Bild oder Textbearbeitung. Deshalb nochmal die Frage:
kann ich das im Firefox deaktivieren?