Zwischenzeitlich hat übrigens auch heise.de von der Sache berichtet:
Hallo,
nach Rückfrage bei Mozilla habe ich erfahren, dass offensichtlich irgendetwas einen Fehler im HTTP-Code ausgelöst hat. Als Workaround hilft es, über about:config den Schalter network.http.http3.enabled per Doppelklick auf false zu setzen.
Update 10.20h: Nun sollte alles wieder funktionieren. Firefox ist ggfs. neuzustarten.
Danke Sören!
Hatte vorab die Addons gecheckt, von meinen wurde heute nur uBlock Origin aktualisiert, um kurz vor 9 Uhr. Das hätte also zeitlich in etwa gepasst. Aber auch nach dessen Deaktivierung trat der Fehler erst noch auf.
Gut, dass die Sache nun so schnell behoben werden konnte (zumindest bisher läuft FF auch bei mir wieder) und ich FF noch nicht über das Hilfe-Menü "bereinigt" hatte (das hätte nämlich u.a. die Addons und deren Einstellungen gelöscht).
So hat es sich bewährt, bei Bugs erstmal - am besten in einem aktiven und kompetenten Forum wie hier 
- zu fragen, ob er anderswo auch vorliegt, bevor man selbst herumprobiert und damit womöglich noch mehr Schaden anrichtet.
Hallo zusammen,
seit dem Update auf FF 96 hängt dieser plötzlich immer mal wieder fest, d.h. ein CPU-Kern behält Volllast und die man kann keine Webseiten mehr laden, bis FF dann irgendwann einen Absturz meldet. Oft passiert nach einem Neustart dann dasselbe wieder.
- Beendet man FF, bleibt ein FF-Task mit der CPU-Volllast bestehen.
- Beendet man FF dann irregulär über den Taskmanager, ist er zwar weg, startet man ihn dann aber neu, hängt er oft erneut.
Ist das bei anderen Usern auch so, könnte das mit dem Update auf Version 96 zusammenhängen?
Hallo zusammen,
sehr unüblich finde ich es in Firefox, dass beim Löschen von Lesezeichen keinerlei Sicherheitsabfrage/Rückfrage erfolgt - selbst beim Löschen ganzer Lesezeichen-Ordner nicht. Einmal versehentlich Löschen statt Bearbeiten geklickt, und schon ist alles weg.
Windows fragt vor dem Löschen von Dateien/Ordnern nach (falls man es nicht abgestellt hat), und die meisten anderen Programme auch.
Als einzige Rettungsoption fand ich die Wiederherstellung aller Lesezeichen über die automatischen Sicherungen, die (fast) täglich angelegt werden. Nur einzelne, versehentlich gelöschte Ordner kann man daraus aber leider nicht wiederherstellen, sondern nur den gesamten Stand, so dass gewollte Änderungen seit der letzten Sicherung dann wieder weg sind.
Gibt es eventuell eine (versteckte) Option in FF, über die man vor dem Löschen von Lesezeichen(-Ordnern) sicherheitshalber gefragt wird, ob man wirklich löschen möchte?
Was passiert aber, wenn man dieselbe Seite in zwei verschiedenen Containern nutzt (dafür ist das Addon ja primär gedacht, also z.B. zwei separate Accounts bei einem Dienst)? Wie kann man dann die Cookies für den einen Container löschen, nicht aber für den anderen?
Was ich mit zu FFMAC auch frage: In der normalen Cookie-Verwaltung erscheinen die nur für bestimmte Container geltenden Cookies nicht. Kann man diese gar nicht verwalten?
Ich habe zwischenzeitlich alle Einstellungen bzw. die zurückgesetzte Container-Liste von Hand wieder nachgestellt. Werde mich hüten, das Addon auch nur kurzzeitig zu deaktivieren.
Die Erweiterung synchronisiert doch mit dem Mozilla Account, daher sollten dort alle Settings sein.
Den verwende ich (zumindest noch) nicht.
Leider hat das Addon einen Haken: Wenn man es (auch nur ganz kurz) deaktiviert und dann wieder aktiviert, sind alle Einstellungen (Namen der Container, diesen zugeordnete Websites) verschwunden, und man muss scheinbar alles von vorn definieren.
Ich verwende diese Erweiterung auch, kann das Verhalten aber nicht bestätigen. Bin zwar am Mac mit macOS unterwegs, doch das sollte keine Rolle spielen.
Eventuell entfernst du die Erweiterung und fügst sie nochmals neu hinzu?
Nach weiterem Prüfen wird die Liste der vorhandenen Container zurückgesetzt, d.h. entfernte Standard-Container erscheinen wieder und selbst ergänzte Container sind weg. Immerhin ist die Site List zu Standard-Containern aber noch da.
Nach weiterer Überprüfung erscheint das Favicon übrigens auch bei nicht per .htaccess geschützten Seiten manchmal nicht in den FF-Lesezeichen, wohl aber im entsprechenden Tab. Daran scheint es daher wohl nicht zu liegen.
Hallo zusammen,
Firefox bietet das Addon "Firefox Multi-Account Containers", mit dem man Websites in verschiedenen "Containern", also weitgehend voneinander getrennten Umgebungen, öffnen kann.
Leider hat das Addon einen Haken: Wenn man es (auch nur ganz kurz) deaktiviert und dann wieder aktiviert, sind alle Einstellungen (Namen der Container, diesen zugeordnete Websites) verschwunden, und man muss scheinbar alles von vorn definieren.
Weiß vielleicht jemand, ob man die getroffenen Einstellungen doch noch irgendwoher wieder restaurieren kann?
Naja, man sieht halt deutlich, dass die Icons der Website-Verknüpfungen viel pixeliger sind als z.B. der Papierkorb. Und wenn ich das jeweilige favicon.ico downloade und auf den Desktop lege, erscheint es auch immer deutlich schärfer als als Verknüpfung.
Hallo zusammen,
normalerweise verwalte ich meine Bookmarks direkt in Firefox. Einige wenige hätte ich aber gern direkt auf dem Windows-Desktop (u.a. auch für Dummy-User, damit diese wichtige Websites so leicht wie möglich finden).
Dazu kann man eine Seite in FF öffnen, dann die URL-Zeile durch Anlicken auswählen und diese dann per Drag&Drop als Verknüpfung auf den Windows-Desktop ziehen. Alternativ kann man auch das Verschlüsselungssymbol links direkt vor der URL (Schloss-Symbol) auf den Desktop ziehen.
Unschön dabei: Die Icons werden auf dem Windows-Desktop immer ziemlich grob aufgelöst dargestellt. Es sieht so aus, als wenn immer die 32x32-Pixel-Version hochskaliert wird, obwohl favicon.ico jeweils auch eine 96x96-Version enthält sowie weitere Versionen (u.a. ms-icon-310x310.png) per Meta-Tags verlinkt sind.
Weiß jemand, welche Favicon-Datei/-Version Windows für Desktop-Verknüpfungen genau verwendet, und lädt Windows diese selbst, oder bekommt es diese vom Browser wie hier Firefox übergeben?
Hallo,
mit offener Sidebar verschwindet der Button zum Schließen der Suchleiste unter Windows und Linux (nicht unter macOS, weil dort der Button auf der entgegengesetzten Seite ist). Der Fehler wird in Firefox 92.0.1 behoben sein.
In der Zwischenzeit lässt sich die Suchleiste aber auch mit der ESC-Taste schließen.
Lieben Dank, Sören! Tatsächlich habe ich die Lesezeichen-Sidebar offen. Danke für den Workaround mit ESC. 92.0.1. wird aber ja wahrscheinlich auch nicht mehr lange auf sich warten lassen.
Hallo zusammen,
seit FF 92 lässt sich die Suchleiste unten, die erscheint, wenn man mit Strg+F ein Wort auf der aktuellen Webseite suchen möchte, nicht mehr wie zuvor entfernen, weil das Kreuzchen dazu, das zuvor immer ganz rechts erschien, nicht mehr vorhanden ist. Ist das ein Bug oder ein "Feature"? 
Hallo Sören,
beim Sichten betroffener Websites stellte ich fest, dass diese per .htaccess Passwort-geschützt sind (Webalizer Webhosting-Statistiken und andere Administrations-Funktionen in Unterordnern, deren Zugangslinks ich lieber nicht veröffentlichen möchte, um keine Hacker anzuziehen).
Bis vor kurzem erschien zu den entsprechenden Bookmarks dennoch das Favicon der jeweiligen Homepage (beim Bookmark der Homepage funktioniert es auch weiterhin), jetzt stattdessen nur noch ein grüner Kreis mit einem weißen, nicht leserlichen Signet darin.
Hallo zusammen,
bei einigen Favoriten wird das Favicon der jeweiligen Seite nicht aktualisiert. Selbst ein Löschen des Favoriten und anschließende Neuanlage, Neuladen der Seite mit Shift+Aktualisieren usw. hilft leider nicht. Im Tab mit der jeweiligen Seite erscheint das Favicon korrekt, nicht aber im Lesezeichen-Menü und in der dazugehörigen Sidebar.
Gibt es hierzu eine Abhilfemöglichkeit?
Schau Dir mal die Erweiterung Don't track me Google an.
Dieses Addon funktioniert genau wie gewünscht, ist mit nur 25 KB winzig klein, benötigt nur den Zugriff auf abgerufene Google-Domains und wird von Firefox empfohlen, so dass es vertrauenswürdig sein sollte - top, danke!
Hallo zusammen,
seit einer Weile sind Links aus Google-Suchergebnissen - zumindest mit Firefox - kaum noch ohne Zusatzaufwand herauskopierbar, da Google ums Verrecken tracken will und alle Links mit einem eigenen Tracking versieht.
Bei einer Google-Suche nach "Firefox" (https://www.google.com/search?q=firefox) wird so aus dem ersten Treffer
zum Beispiel:
Seltsam: Beim ersten Mouseover erscheint zumindest im Firefox noch die letztendliche Ziel-URL, wenn man draufklickt, geht es aber über http://www.google.com/, und geht man dann zurück zur Google-Ergebnisseite, erscheint dann auch beim Mouseover sofort die Google-URL. Und geht man direkt per rechte Maustaste auf "Link-Adresse kopieren", wird auch sofort die Google-URL kopiert, und auch dann erscheint beim nächsten Mouseover dann diese.
Man muss also nun immer den URL-Parameter manuell aus der Google-URL herausschneiden, und dessen URL-Codierung dann auch noch irgendwie rückgängig machen?
Ziel von Google wird sein: Man soll keine Links auch Suchergebnissen mehr weiterleiten oder anderweitig verwenden, sondern stattdessen "Suche bei Google nach Firefox", damit Google jedes Mal neu wieder Anzeigen vermarkten kann? Die tun wirklich alles, um ihr Monopol knallhart auszuquetschen wie eine Zitrone.
Interessant ist, dass in Googles eigenem Browser Chrome die tatsächliche Ziel-URL kopiert wird und nicht die Google-Tracking-URL. Ob Mozilla hier nachziehen kann?
Das Performance-Problem ließ sich zwischenzeitlich mit einer serverseitigen Änderung der Caching-Vorgaben lösen.
Ganz konkret war in punkto Caching übrigens zumindest beim hier verwendeten Hoster der Knackpunkt, dass Apache 2.4 den MimeType "image/webp" standardmäßig noch nicht kannte, so dass man ihn vor einem etwaigen Expires-Kommando z.B. im .htaccess erst selbst ergänzen muss:
AddType image/webp .webp
ExpiresByType image/webp "access plus 1 week"Tatsächlich, die Anführungszeichen machen den Unterschied. Auch wenn die Argumente in CSS anderswo auch ohne sie funktionieren, funktioniert type() innerhalb von image-set nur mit Anführungszeichen (egal ob ein- oder zweistrichig) zwischen den Klammern. Dankeschön!
Jetzt bleibt zu hoffen, dass Chrome, Edge usw. das type()-Argument in image-set auch bald berücksichtigen, am besten auch ohne das Präfix -webkit-.