Arbeitsprofil(default)überhaupt nicht mehr zu gebrauchen!

Zitat von loshombre

Auf jeden Fall steht das jetzt wohl ziemlich fest(und ehrenwerter Kamerad Schnelle Sole kann das auch bestätigen), daß meine Schraubarbeiten [Blockierte Grafik: http://fool.exler.ru/sm/tnp.gif] da keine Rolle mehr spielen dürften.

Das bestätige ich zu 100%, da ich das Fehlverhalten in einem meiner Testprofil nachvollziehen konnte.

Für mich liegt das Problem nach wie vor darin, dass das erste Searchplugin, welches überprüft, ob Updates vorhanden sind, den Eintrag xmlns:NS1="http://home.netscape.com/WEB-rdf#" in die localstore einzutragen versucht. Wenn nun dieser Code NS1= schon durch irgendeine Erweiterung belegt ist, schreibt das Searchplugin einfach nichts. Nur: beim 2. Updateversuch kann es wegen dieses fehlendes Eintrags den nach dem ersten Updateversuch bestehenden Eintrag NS1:LastPingDate="1126011710" nicht überschreiben, sondern fügt einen zweiten Eintrag hinzu (soweit ich das in den Bug-Kommentaren richtig vestanden habe).

Beim nächsten Start will Firefox die localstore auslesen, findet 2 LastPingDate-Einträge, glaubt, dass die localstore defekt ist (da maximal ein LastPingDate-Eintrag vorhanden sein darf) und legt kurzerhand eine neue mit den Standardeinstellungen an. Dadurch sind dann natürlich alle Anpassungen weg.

Da zwischen den beiden Update-Versuchen durchaus mehrere Tage liegen können, wird der Fuchs nicht gleich nach dem ersten, sondern erst nach dem zweiten Update-Versuch dieses Fehlverhalten zeigen.

Wenn jemand mir sagen kann, wo ich im searchplugin den zeitlichen Abstand zwischen 2 Updateversuchen einstellen kann, werde ich nächste Woche mal versuchen, diese Theorie auf meinem 2. Rechner mit einem komplett neu installierten Fuchs nachzuvollziehen.

Zitat von Road-Runner

Wenn jemand mir sagen kann, wo ich im searchplugin den zeitlichen Abstand zwischen 2 Updateversuchen einstellen kann, werde ich nächste Woche mal versuchen, diese Theorie auf meinem 2. Rechner mit einem komplett neu installierten Fuchs nachzuvollziehen.

http://mycroft.mozdev.org/deepdocs/brows…updateCheckDays

Danke @ Dr. Evil.

Wenn ich das richtig sehe, muss ich also den Zweitrechner mindestens 1 Tag (= 24 Stunden) laufen lassen, um zu sehen, ob der zweite Update-Versuch mitspielt.

Oder kann ich da irgendwas wie z.B. 0,2 Tage eingeben?

du kannst glaub in der localstore.rdf etwas mogeln und das Datum des letzten Updates runtersetzen. Dafür sind diese LastPingDate-Einträge ja anscheinend da. Das Datumsformat scheint in Sekunden seit dem 1.1.1970 angegeben zu sein. Wenn du also 60*60*24=86400 abziehst, ist das letzte Update einen Tag her.

Danke, ich werde das dann mal versuchen.

Schlimmstenfalls läuft der Rechner eben mal 2 Tage und Nächte hintereinander (wäre ja nicht das erste Mal :wink: ).

Damit ist mein geplanter Test hinfällig; das Verhalten Deines Testprofils bestätigt meine Theorie.

Meiner Meinung nach gibt es nur eine definitive Abhilfe:

- neues Profil erstellen
- den Code xmlns:NS1="http://home.netscape.com/WEB-rdf#" an der richtigen Stelle in der localstore einfügen
-Erweiterungen installieren und gewünschte Anpassungen vornehmen.

Durch den manuellen Eintrag ist dann der Code NS1= besetzt, später installierte Erweiterungen benutzen dann NS2 bis NSx.

Da aber die searchplugins für das Update nur den Code NS1= brauchen (und der ja dann vorhanden ist) sollte dann das Problem nicht mehr auftreten.

Bisher ist ja wohl noch nicht geklärt, warum der Bug zwar reproduzierbar ist, aber nicht bei allen auftriit, die z.B. TMP verwenden und dort die Funktion "Sitzung wiederherstellen" aktiviert haben.

Könnte es sein, dass der Bug nur zuschlägt, wenn man ein neues Profil für Fx 1.5 verwendet? Ich habe nämlich beim Update kein neues Profil erstellt und in meiner localstore.rdf ist LastPingdate NS2 zugewiesen und TMP verwendet NS1. Und bei mir tritt der Fehler nicht auf.

Alexander

Zitat von Alexxander

Könnte es sein, dass der Bug nur zuschlägt, wenn man ein neues Profil für Fx 1.5 verwendet? Ich habe nämlich beim Update kein neues Profil erstellt und in meiner localstore.rdf ist LastPingdate NS2 zugewiesen und TMP verwendet NS1. Und bei mir tritt der Fehler nicht auf.

Das ist durchaus möglich.

Vermutung: die searchplugins suchen nach xmlns:NSx="http://home.netscape.com/WEB-rdf#" und wollen diesen Eintrag nur unter NS1 anlegen, wenn noch kein Eintrag vorhanden ist.

Dazu würde dieser Eintrag in der Bugmeldung Kommentar #6) passen:

Zitat

In my old 1.0.x profile, BTW, LastPingDate was assigned to NS4 namespace name,
which stands for the (correct) namespace "http://home.netscape.com/WEB-rdf#",
while namespaces from extensions were assigned to NS8, NS9 and NS10.

Warum das Searchplugin-Update unbedingt den Eintrag unter NS1 anlegen will (wenn noch keiner unter NSx vorhanden ist) anstatt einfach die nächste freie Nummer zu nehmen, weiss ich nicht. Dazu müsste schon ein Programmierer Stellung nehmen.

Zitat von Road-Runner

Meiner Meinung nach gibt es nur eine definitive Abhilfe:

- neues Profil erstellen
- den Code xmlns:NS1="http://home.netscape.com/WEB-rdf#" an der richtigen Stelle in der localstore einfügen
-Erweiterungen installieren und gewünschte Anpassungen vornehmen.

Durch den manuellen Eintrag ist dann der Code NS1= besetzt, später installierte Erweiterungen benutzen dann NS2 bis NSx.

Da aber die searchplugins für das Update nur den Code NS1= brauchen (und der ja dann vorhanden ist) sollte dann das Problem nicht mehr auftreten.

@ loshombre:

wenn Du nach diesem Vorschlag verfährst, musst Du auch das automatische Update der Searchplugins aktiviert lassen, sonst tritt der Fehler höchstwahrscheinlich nicht auf.

Und setzte mal in einem Searchplugin die updateCheckDays="7" auf 1 Tag, dann siehst Du schneller, ob es mit meinem Vorschlag klappt.

Ich wünsche es Dir jedenfalls.

Der Code sollte ganz am Anfang der Datei stehen.

Hier mal ein Auszug aus meiner localstore:

Zitat

<?xml version="1.0"?>
<RDF:RDF xmlns:NS1="http://home.netscape.com/WEB-rdf#"
xmlns:NC="http://home.netscape.com/NC-rdf#"
xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

Um welche searchplugins geht es eigentlich, die nach dem update für die probleme sorgen, die des programmordners oder die des profilordners?

im programmordner sind die von mozilla default installierten searchplugins, im profilordner die via "suchmaschine hinzufügen" selbst gedownten searchplugins?

mein google searchplugin (der amerikanischen en-us version) des programmordners lautet:

# Mozilla/Google plug-in by amitp+mozilla@google.com


<search 
   name="Google"
   description="Google Search"
   method="GET"
   action="http://www.google.com/search"
   queryCharset="utf-8"
>


<input name="q" user>
<inputnext name="start" factor="10">
<inputprev>
<input name="ie" value="utf-8">
<input name="oe" value="utf-8">


<interpret 
    browserResultType="result" 
    charset = "UTF-8"
    resultListStart="<!--a-->" 
    resultListEnd="<!--z-->" 
    resultItemStart="<!--m-->" 
    resultItemEnd="<!--n-->"
>
</search>


<browser
    update="https://addons.mozilla.org/searchplugins/updates/google.src"
    updateIcon="https://addons.mozilla.org/searchplugins/updates/google.gif"
    updateCheckDays="1"
>

mein zugefügtes google-de im profilordner

# Mycroft Search Plugin for Mozilla, Firebird, Netscape 6+, Beonix browsers 
# Mycroft Homepage: http://mycroft.mozdev.org
#
# SearchSite: Google DE (All Web Search) (www.google.de)
# Status: Working Full
# Country: DE
# Language: de
# Category: General
#
# Adaped by Alan Bramley from GoogleDE (German Sites) by amitp & modified by  Wolfgang Schroedl and Julius Ross
# Created: 18 April, 2004
# Last updated December 06, 2005 (CC, TIDY)




<SEARCH
   version = "7.1" 
   name="Google Deutschland"
   description="Google Deutschland Suche Das Web"
   method="GET"
   action="http://www.google.de/search"
   searchform="http://www.google.de"
   queryCharset="UTF-8"
>


<input name="num" value="20">
<input name="hl" value="de">
<input name="q" user>
<input name="btnG" value="Google-Suche">
<input name="sourceid" value="Mozilla-search">


<inputnext name="start" factor="20">
<inputprev>


<interpret 
  browserResultType="result"
  charset="UTF-8"
  resultListStart="<!--a-->" 
  resultListEnd="<!--z-->" 
  resultItemStart="<!--m-->" 
  resultItemEnd="<!--n-->"
>


</search>


<browser
   update="http://mycroft.mozdev.org/update.php/id0/googleDE_AllWeb.src" 
   updateicon="http://mycroft.mozdev.org/update.php/id0/googleDE_AllWeb.gif" 
   updateCheckDays="7"
>

Frage: wenn die searchplugins, die im profilordner sind, nach dem update für probleme sorgen, wáre es nicht ein workaround oder eine empfehlung an user mit gleichen problemen, alle searchplugins in den programmordner zu verlagern? an dem bug:307558 arbeitet wohl eh keiner mehr :?

gruss

Zitat von loshombre

Meine Searchplugins waren/sind von Anfang an alle im Programmordner.

es wird immer verwirrender, dann ist ja jedes profil in gefahr, mit dem ich gerade surfe, wenn die searchplugins updaten und die localstore beschädigen.

ich weiss auch garnicht, was die updaterei täglich öder wöchentlich soll, ich habe jetzt allen dafault searchplugins im programmordner das updaten verboten durch einfügen von # mittels texteditor in die betreffenden *.src-dateien, siehe
http://www.firefox-browser.de/forum/viewtopi…p=213140#213140

mich hatte das updategehabe der searchplugins eh schonmal geärgert.
http://www.firefox-browser.de/forum/viewtopic.php?t=19640

hab dem abdulkadir mal ne pn gechickt und auf diesen thread hingewiesen, vielleicht kann loshombre ja mal doch eine nicht zu lange pn an axel hecht schreiben und auf diesen thread in zusammenhang mit dem bug verlinken, auch wenn axel hecht keine pn's wünscht und keinen support erteilt, aber dies ist vielleicht eine ausnahme.
http://www.firefox-browser.de/forum/profile.…wprofile&u=5107

gruss
:wink:

Zitat von Amsterdammer

es wird immer verwirrender, dann ist ja jedes profil in gefahr, mit dem ich gerade surfe, wenn die searchplugins updaten und die localstore beschädigen.

Wieso soll jedes Profil in Gefahr sein? Das Problem liegt in den fehlerhaften Erweiterungen! Nur weil die ihren Mist irgendwo abladen, wo sie nichts verloren haben. Denn ohne die blöden Erweiterungen passiert selbst nach dem 100. Search-Plugin-Update nichts.
Es mag in Firefox unglücklich gelöst sein, dass er dann alle Einstellungen verliert. Aber bei Fehlern ist es nunmal so.

Außerdem hat jedes Profil seine eigene localstore.rdf insofern sind nie alle Profile betroffen.

Wenn das Searchplugin-Update den betreffenden Eintrag unter NS1= abgelegt hat, bevor eine Erweiterung sich diesen Code krallen konnte; oder wenn das Searchplugin-Update generell deaktiviert ist, sollte das Problem nicht vorkommen.

Abgesehen davon wäre es imho logisch, wenn beim Searchplugin-Update automatisch die nächste freie NSx-Nummer genommen würde anstatt sich auf NS1 zu beschränken. Schliesslich wird auch eine andere NS-Nummer übernommen, wenn sie in einem alten Profil als NS2= festgeschrieben war (siehe Posting von Alexxander etwas weiter oben).

Sorry, ich muss wiedersprechen, master x, es ist ein firefox bug:
customized toolbars are reset to default because of corrupt localstore.rdf after search plugin update check,
der hier mitspielt. jedes profil, mit dem man gerade surft, ist betroffen wegen des bug, sofern bestimmte erweiterungen, die hier und im bug besprochen sind, installiert sind.

aber es ist natürlich ein streit um des kaisers bart, wer oder was verantwortlich ist (firefox oder erweiterung), und wer oder was zu ändern ist. Gäbe es keine erweiterungen in firefox, würde ich sicher nicht mit firefox browsen.

immerhin gibt es einen bugfix, der von Benjamin Smedberg abgewertet wurde (review: "-")

ich bleib bei meinem workaround (siehe http://www.firefox-browser.de/forum/viewtopi…p=213140#213140), um zu verhindern, das in zukunft bei einer noch zu installierenden erweiterung mein profil wie das von loshombre "übern zaun hängt"