Mich würde noch interessieren, ob bekannt ist, welcher Eintrag in den prefs jetzt den Fehler ausgelöst hatte.
Die 'prefs' hatte gar nichts "ausgelöst". Der Fehler wird verursacht durch einen FF-Bug: hier. Das Neuanlegen der 'prefs.js' (+Neustart) und das darauf folgende Überschreiben der 'prefs' mit der alten Datei(+Neustart), hat nichts anderes bewirkt, als dass das Sichern der Session ausgeschaltet wurde (das ist wohl die default-Einstellung) und dann wieder eingeschaltet wurde. Und genau das ist der 'Workaround' um den bestehenden FF-Bug zum umgehen. Stand aber alles auch weiter oben. Siehe Beiträge von Milupo und mir.
Und gerade sehe ich, dass Zitronella das auch noch mal erklärt hat.
Das zweite deiner Bilder zeigt die verwendeten Userscripte. Sei erwähnt.
hattest du vorher nicht explizit erwähnt, sorry.
Explizit geschrieben hatte ich das nicht, sondern unter "usw." zusammengefasst. Ich hatte zum Testen den ganzen Chrome-Ordner 'deaktiviert'.
Ob nun die Fehler in der Konsole von den (gezeigten) userscripten auch darauf zurückzuführen sind, unbekannt, jedenfalls werfen die reichlich Meldungen aus, auch wenn es funktioniert, mich würde das fuchsen.
Jedes User-Skript wirft genau ein Meldung aus.
Meiner Meinung nach ist der Grund entweder das gänzliche Fehlen oder die falsche Verwendung einer globalen Variable, die feststellt, ob das Hauptelement des Browsers vorhanden ist und im richtigen Kontext aufgerufen wird. Falls es nicht vorhanden ist, wird wieder zum aufrufenden Kontext zurückgesprungen. Ein Code wie if (!window.gBrowser){ return;} verhindert das Werfen der in der Konsole angezeigten Exception. Da aber die Exception nichts anderes macht, wie die 'return'-Anweisung (solange der aufrufende-Kontext eine 'catch'-Anweisung hat), passiert effektiv exakt dasselbe. Natürlich ist das ein Bug und ich habe ihn bis auf ein UserScript jetzt beseitigt. War mir aber bis heute nicht so wichtig, da die Skripte einwandfrei funktioniert haben. Aborix könnte dazu wohl genaueres sagen...