Mit Firefox 38.0.1 tritt das Problem der teilweise verzögerten Favicons in der Favoriten-Sidebar nicht mehr auf - ohne jegliche sonstigen Änderungen am System.
Gut, dass ich den Hinweisen hier nicht nachgegangen bin und mir nicht einen Wolf abgerödelt habe mit dem Ändern diverser anderer Einstellungen oder dem (De-)Installieren anderer Software (und nun mein ursprüngliches System hätte wiederherstellen dürfen).
Ich wollte eigentlich nur Alphazalpha aus #17 unterstützen, gebe aber nun auf und werde dann wohl in Zukunft keine potentiellen FF-Bugs mehr hier thematisieren, da dies strikt unerwünscht zu sein scheint. Denn die Reaktion ist stets stereotyp: Der Fehler wird bei einem selbst verortet, man soll dann probeweise diverse Einstellungen usw. am PC ändern. Tut man dies aus Angst vor dadurch unerwartet produzierten neuen Problemen nicht, wird man "gedisst", und tut man es doch, es ändert sich aber nichts, verläuft alles im Sande. Auf jeden Fall haben einige User immer, immer das letzte Wort, man hat automatisch immer schon von Beginn an verloren. Ich strecke die Fühler 
Naja, wenn bis FF 35 alles einwandfrei lief und seit FF 36 schlagartig das Problem auftritt, und das bei mehreren Usern, muss doch da etwas sein. Ob es nun direkt an FF liegt oder indirekt (im Zusammenspiel mit anderen Komponenten) - eine ausgereifte Software weiß doch i.d.R. um gängige Konflikte und versucht, diese auszuschalten.
@Sören: Peace!
Es ist betrüblich, dass man als User bei Hotlines und in bestimmten Kreisen Bugs erst haarklein "beweisen" soll, bevor man für voll genommen wird - vielmehr wird man sonst als fauler Sack oder Idiot in die Ecke gestellt. Schade.
PS: Welcher normale Firefox-User legt sein "Profil" ständig neu an, geschweige denn wer weiß, was das genau ist und wofür es gut ist? Dürfen somit nur FF-Insider hier posten?
Fazit: Keep cool, Frequent Posters
Wie gesagt: So schwerwiegend, dass man mit dem Bug nicht mehr arbeiten kann, ist es ja auch wieder nicht. Und da der Bug ja bei einem anderen User auch vorkommt (s.o.), liegt es scheinbar nicht an meinem System.
Ich hatte in der Vergangenheit auch schon mehrmals mühsam selbst experimentiert und diverse Einstellungen geändert, um dann feststellen zu müssen, dass es doch ein Bug war und ich am besten einfach nichts getan hätte.
Da warte ich dann lieber noch etwas ab, bis es die FF-Entwickler selbst bemerken und fixen.
Ich kenne mich damit nicht so gut aus, weil ich das nicht gerade täglich mache, und möchte einfach vermeiden, dass es zu unerwarteten "Nebenwirkungen" kommt. Auf einem privaten Experimentier-PC kein Problem, auf meinem Geschäfts-PC riskiere ich aber grundsätzlich gar nichts, was irgendwie nach Risiko riecht. Zudem hatte man mir früher in anderen Foren auch immer mal wieder empfohlen, dies und jenes zu probieren, es könne nichts schief gehen - dann kam es aber trotzdem doch zu Problemen. Da bin ich ein gebranntes Kind.
Hallo Boersenfeger,
der Bug tritt ja schlagartig seit FF 36.0 auf (und wurde nun mit FF 37.0 ebenfalls schlagartig weniger) - da macht es aus meiner Sicht weniger Sinn, selbst herumzudoktern. So eilig ist es ja auch wieder nicht, man kann zur Not eine Weile damit leben - wenn der Bug dann irgendwann gefixt wird.
Übrigens erscheinen die Favicons auch dann immer alle vollständig, wenn man einen Favoritenordner zum zweiten Mal direkt nacheinander öffnet. Nur beim ersten Öffnen fehlen einige Favicons immer, bis man sie per Mouseover abfährt.
In 37.0.1 ist der Bug zwar weniger frequent, tritt aber immer noch auf.
In Firefox 36.0.3 (nach 36.0.1 die zweite Update-Version von 36) ist das Problem immer noch nicht gelöst 
Hallo zusammen,
ich habe eine recht umfangreiche Favoriten-Sammlung, die ich in Ordnern strukturiert per Favoriten-Sidebar nutze.
Seit dem Update des FF auf 36.0 erscheinen die Favicons teilweise nicht bzw. erst dann, wenn man deren Position mit der Maus abfährt (Mouse-over).
Ist das bei Euch auch so?
PS: Auch NoScript reagiert plötzlich anders, d.h. wenn man über das NoScript-Menü links oben eine URL freigibt und mit der Maus das NoScript-Kontextmenü verlässt, verschwindet es nicht von allein, sondern erst, wenn man irgendwo außerhalb des Menüs klickt. Liegt das zufällig auch an FF 36.0, oder am letzten NoScript-Update?
Bernd,
wer mault hier immer ? Lass uns sachlich bleiben und die persönlichen Anfeindungen heute mal für uns behalten 
Tab schließen ist kein wirklich praktischer Workaround, wenn man auf einen Link klickt, der lädt z.B. 5s lang nicht, und dann auf einen anderen Link auf derselben Seite klickt. Dann müsste ich den Tab schließen und die Linkseite erst neu anwählen.
Unlogisch ist das Verhalten des FF ab V. 24 ja auch definitiv, da es kein Szenario gibt, wo es Sinn machen würde - eigentlich sollte daher gar kein Workaround nötig sein.
Hallo Sören,
aktuell tritt es immer noch auf, ja, leider. Hättest Du einen Link, unter dem ich die Problembeschreibung ohne großen Aufwand wie Registrierung etc. von hierher rüberkopieren könnte?
Danke für den Ratschlag, ich belasse es aber aus Aufwandsgründen bei der Schilderung hier und hoffe, Mozilla bemerkt die Sache auch selbst.
Jetzt bin ich nicht nur selbst schuld, sondern habe auch noch absichtlich Beispiel-URIs nicht als solche gekennzeichnet?
Zur Reproduzierbarkeit: Man nehme einfach nur irgend eine Website, die mindestens einige Sekunden lädt (eben so lange, dass man nach deren Aufruf in der FF-Adresszeile eine andere URL eingeben oder über z.B. über die Bookmarks eine andere anklicken kann). Lässt sich bei Bedarf auch selbst herstellen, indem man z.B. einfach ein PHP-Skript mit längerer Wartezeit schreibt.
Diese aufrufen, und dann während des Ladevorgangs / während der Wartezeit eine andere URI eingeben oder anklicken, die sofort erscheint. Sobald die länger ladende Website dann fertig geladen wurde, erscheint diese dann plötzlich statt der zweiten.
Bitte die Diskussion nun nicht auf konkrete Websites und deren Ladezeit verlagern. Unbestritten ist doch, dass es URIs gibt, die (manchmal oder immer) etwas länger laden (ob es nun Tippfehler-URIs oder reguläre sind).
Und es macht eben keinen Sinn, dass FF zwischenzeitlich stattdessen aufgerufene URIs dann plötzlich nachträglich durch die im Hintergrund geladenen, alten URIs ersetzt. Denn wer auf URI 1 klickt, welche dann etwas länger lädt, und dann stattdessen zu URI 2 wechselt - der beabsichtigt eben sicher nicht, dass dann plötzlich im Nachhinein URI 1 URI 2 überschreibt.
Es handelt sich ja nicht um ein Weltuntergangs-Problem, aber schön und sinnig ist es eben nicht, und bis FF 23 kam es auch nicht vor (d.h. es geht offenbar auch ohne).
Generell ändert das aber nichts am besagten, aus meiner Sicht fehlerhaften (denn meiner Meinung nach spricht nichts dafür) Verhalten seit FF 24.0.
Kein Haufen Addons, ausschließlich NoScript, sonst gar nichts. VDSL-Leitung, schneller Rechner. Aber, wie immer hier: Der anfragende User ist natürlich selbst schuld. Sorry für das Posting.
Hallo zusammen,
och Mensch, die abc-URIs waren doch nur erfundene Beispiele, und bei http://www..abc.de kommt der Timeout tatsächlich schneller als bei anderen Tippfehler-URIs. Es gibt auch immer wieder Tippfehler-URIs, bei denen der Timeout erst nach 10-20s kommt. Versucht z.B. mal http://tippfehler.telekom.de/ (da dauert es bei mir beim ersten (!) Mal ca. 10s) - zudem: Hängt die Ladezeit nicht vielleicht auch vom eigenen ISP ab?
PS: Ich habe den aktuellen FF 26.0 (das Problem tritt nur SEIT 24.0 auf...).
Hallo zusammen,
so langsam nervt Firefox in dieser Hinsicht, was das "Multithread-Loading" (oder wie man es nennen soll) angeht: Wenn ich z.B. auf die Seite http://www.abc.de surfen möchte und erst versehentlich http://www..abc.de eingebe, lädt Firefox erst einmal länger. Ich bemerke den Tippfehler und gebe http://www.abc.de ein, die Seite erscheint dann ziemlich schnell. Im Hintergrund versucht FF nun aber ärgerlicherweise weiter, http://www..abc.de zu laden, bis es ein Timeout gibt und die zwischenzeitlich geladene Seite http://www.abc.de dann plötzlich durch "Fehler: Server nicht gefunden" ersetzt wird.
Wo soll der Sinn dieses erst seit FF 24.0 eingeführten Verhaltens liegen, warum überschreibt/beendet ein neuer Seitenaufruf nicht mehr - wie bis FF 23 - alle vorherigen Aufrufe?
Hallo Sören,
danke für Deine sehr gute Erläuterung! Ich werde es nun mal ein paar Tage speziell daraufhin untersuchen und prüfen, ob die Leerzeichen verschwinden, je nachdem, wie ich den zu kopierenden Text markiere.
