Tumbleweed: userChrome.css wird von firefox nicht geladen
Hi, ich verzweifele langsam. Unter openSUSE leap 15.5 habe ich ein userChrome.css eingerichtet, das firefox auch artig läd und anwendet. Nun versuche ich -- an anderem Ort -- das gleiche mit firefox unter Tumbleweed, aber firefox will das userChrome.css ums Verrecken nicht laden. (Tumbleweed wurde gestern Abend aktualisiert, ist also auf dem aktuellen Stand.) Kann das jemand bestätigen, oder übersehe ich etwas? Zum Schluss hatte ich sogar ~/.mozilla gelöscht und firefox komplett neu eingerichtet, aber es änderte sich nichts. Was habe ich gemacht? Über about:support das Profiles Verzeichnis gefunden (nach dem neuen Einrichten gab es sowieso nur noch eines). Dort das Verzeichnis chrome angelegt und in diesem Verzeichnis die Datei userChrome.css. In about:config habe ich das flag toolkit.legacyUserProfileCustomizations.stylesheets auf true gesetzt. Damit sollte firefox das userChrome.css laden. Tut es aber nicht. Das kann ich über Inspect und dort unter Stylesheets prüfen, das userChrome.css wird nicht angezeigt. Wenn ich diese Datei aber von dort manuell nachlade, funktioniert sie, die css-Datei ist also korrekt, i.e., der Fehler kann nicht in der userChrome.css Datei selbst liegen. In der firefox Console finde ich auch keine verdächtige Meldung. Vor dem Löschen von ~/.mozilla hatte ich noch firefox direkt aus dem Internet heruntergeladen und es damit versucht. War dieselbe Version, wie die von Tumbleweed, und damit hatte es genauso wenig funktioniert. Warum wird das userChrome.css nicht geladen? Was übersehe ich???? Oder unterstützt firefox dies in der neuen Version nicht mehr? (Leider kann ich nicht nachsehen, welche Version openSUSE leap 15.5 hat.) Vielen Dank für Eure Hilfe Karl
Wird das File tatsächlich beim Start von Firefox nicht gelesen (mit ls -ltu zu sehen) oder wird der Inhalt ignoriert? Hier habe ich unter 15.5 und Tumbleweed dieselbe firefox-Konfiguration, und wie du toolkit.legacyUserProfileCustomizations.stylesheets=true gesetzt. Beide Firefoxe sind die aktuellen, 115.9.1esr bei Leap und 124.0.1 bei Tumbleweed (Stand von vorgestern). Laut ls -ltu werden beide userChrome.css gelesen, ob sie auch verstanden würden, weiß ich nicht, drin ist alles auskommentiert. -- Viele Grüße Michael
On Sonntag, 7. April 2024 16:11:36 CEST Michael Behrens wrote:
Wird das File tatsächlich beim Start von Firefox nicht gelesen (mit ls -ltu zu sehen) oder wird der Inhalt ignoriert?
Ja, inzwischen bin ich mir sicher, dass firefox userChrome.css nicht liest. War nicht ganz so einfach, denn ich musste atime erst verstehen. Scheint nämlich nur dann beim Lesen aktualisiert zu werden, wenn die letzte atime mehr als einen Tag alt ist. "cat" ändert atime also einmal am Tag. Dann passiert bis zum nächsten Tag nichts mehr. Und jetzt bin ich sicher, dass firefox die Datei _nicht_ ließt.
Beide Firefoxe sind die aktuellen, 115.9.1esr bei Leap und 124.0.1 bei Tumbleweed (Stand von vorgestern).
Meine firefox version ist 124.0.2, nicht 124.0.1 Viele Grüße Karl
Am 10.04.24 um 07:47 schrieb Karl Weber:
On Sonntag, 7. April 2024 16:11:36 CEST Michael Behrens wrote:
Wird das File tatsächlich beim Start von Firefox nicht gelesen (mit ls -ltu zu sehen) oder wird der Inhalt ignoriert?
Ja, inzwischen bin ich mir sicher, dass firefox userChrome.css nicht liest.
War nicht ganz so einfach, denn ich musste atime erst verstehen. Scheint nämlich nur dann beim Lesen aktualisiert zu werden, wenn die letzte atime mehr als einen Tag alt ist. "cat" ändert atime also einmal am Tag. Dann passiert bis zum nächsten Tag nichts mehr. Und jetzt bin ich sicher, dass firefox die Datei _nicht_ ließt.
Beide Firefoxe sind die aktuellen, 115.9.1esr bei Leap und 124.0.1 bei Tumbleweed (Stand von vorgestern).
Meine firefox version ist 124.0.2, nicht 124.0.1
Viele Grüße Karl
Hi, sicher, dass cat die access-time überhaupt ändert??? Ich hab hier grad mal getestet: joe@linux:~> ls -lu --full-time insgesamt 532 -rw-r--r-- 1 joe users 325002 2023-11-10 08:13:37.104229763 +0100 4982653251-4.pdf joe@linux:~> cat 4982653251-4.pdf >/dev/null joe@linux:~> ls -lu --full-time insgesamt 532 -rw-r--r-- 1 joe users 325002 2023-11-10 08:13:37.104229763 +0100 4982653251-4.pdf zugegebenermaßen hätte ich bei "access time" auch erwartet, dass die sich ändert... aber, sie ändert sich nicht mal, wenn ich die Datei in ein anderes Verzeichnis verschiebe und dann wieder zurück... bin etwas verwirrt, aber zugegebenermaßen habe ich in 35 Jahren Arbeit mit unixoiden Systemen die "access time" noch nie gebraucht und mich mit deren Bedeutung noch nie beschäftigt... -- cu jth
On Mittwoch, 10. April 2024 08:14:31 CEST Jörg Thümmler wrote:
Hi,
sicher, dass cat die access-time überhaupt ändert???
Ja, ganz sicher. Gestern um 07:06 und heute um 07:30, jeweils morgens und dann den Rest des Tages nicht mehr. Und das passt hierzu: https://superuser.com/questions/464290/why-is-cat-not-changing-the-access-ti... Und dort steht auch, dass und warum es bei Dir anders sein kann. Viele Grüße Karl
Am 10.04.24 um 08:40 schrieb Karl Weber:
On Mittwoch, 10. April 2024 08:14:31 CEST Jörg Thümmler wrote:
Hi,
sicher, dass cat die access-time überhaupt ändert???
Ja, ganz sicher. Gestern um 07:06 und heute um 07:30, jeweils morgens und dann den Rest des Tages nicht mehr.
Und das passt hierzu:
https://superuser.com/questions/464290/why-is-cat-not-changing-the-access-ti...
Und dort steht auch, dass und warum es bei Dir anders sein kann.
Viele Grüße Karl
Hi, passt, und jetzt, wo Du's erwähnst... in einer fernen Vergangenheit war da mal was... ist alles noatime hier... Danke für den klärenden Hinweis! -- cu jth
Am 10.04.2024 um 07:47 schrieb Karl Weber:
On Sonntag, 7. April 2024 16:11:36 CEST Michael Behrens wrote:
Wird das File tatsächlich beim Start von Firefox nicht gelesen (mit ls -ltu zu sehen) oder wird der Inhalt ignoriert?
Ja, inzwischen bin ich mir sicher, dass firefox userChrome.css nicht liest.
War nicht ganz so einfach, denn ich musste atime erst verstehen. Scheint nämlich nur dann beim Lesen aktualisiert zu werden, wenn die letzte atime mehr als einen Tag alt ist. "cat" ändert atime also einmal am Tag. Dann passiert bis zum nächsten Tag nichts mehr. Und jetzt bin ich sicher, dass firefox die Datei _nicht_ ließt.
Völlig sinnloses Unterfangen falls Filesystem mit noatime gemountet ist. Wesentlich besser ist inotifywait userChrome.css in einer Konsole laufen zu lassen und dann den Firefox starten. Manfred
On Wed, 2024-04-10 at 07:47 +0200, Karl Weber wrote:
On Sonntag, 7. April 2024 16:11:36 CEST Michael Behrens wrote:
Wird das File tatsächlich beim Start von Firefox nicht gelesen (mit ls -ltu zu sehen) oder wird der Inhalt ignoriert?
Ja, inzwischen bin ich mir sicher, dass firefox userChrome.css nicht liest.
War nicht ganz so einfach, denn ich musste atime erst verstehen. Scheint nämlich nur dann beim Lesen aktualisiert zu werden, wenn die letzte atime mehr als einen Tag alt ist. "cat" ändert atime also einmal am Tag. Dann passiert bis zum nächsten Tag nichts mehr. Und jetzt bin ich sicher, dass firefox die Datei _nicht_ ließt.
Beide Firefoxe sind die aktuellen, 115.9.1esr bei Leap und 124.0.1 bei Tumbleweed (Stand von vorgestern).
Meine firefox version ist 124.0.2, nicht 124.0.1
Ich habe hier ebenfalls 124.0.2 mit custom userChrome.css und userContent.css und beides funktioniert einwandfrei. Gibt es bei dir in ~/.mozilla/firefox/ evtl. mehrere Profile und Firefox lädt beim start ein anderes als das welches du erwartest? Bei mir gibt es z.B. khfjuikd.default und ghopreuy.default-release, welches davon tatsächlich verwendet wird kannst du wahrscheinlich am einfachsten herausfinden indem du mal `firefox -p` ausführst.
participants (5)
-
Jörg Thümmler -
Karl Weber -
Manfred Kreisl -
Michael Behrens -
tux93＠opensuse.org