Beiträge von Minotauros

Du benötigst Hilfe bezüglich Firefox? Bitte stelle deine Frage im öffentlichen Bereich des Forums und nicht per Konversation an wahllos ausgesuchte Benutzer. Wähle dazu einen passenden Forenbereich, zum Beispiel „Probleme auf Websites“ oder „Erweiterungen und Themes“ und klicke dann rechts oben auf die Schaltfläche „Neues Thema“.

    Vielen Danke für deine Hilfe.


    Durch diesen Beitrag bin ich auf die Idee gekommen auch mal die Linuxversion von Firefox 2.0.0.1 de zu testen, wie beschrieben tritt dort der gleiche Fehler auf:


    rob@ubuntu:~$ ls -l /opt/firefox/defaults/profile
    insgesamt 24
    -r--r--r-- 1 root root 7137 2006-09-28 19:06 bookmarks.html
    drwxr-xr-x 2 root root 4096 2006-12-09 00:53 chrome
    -r--r--r-- 1 root root 153 2005-07-24 19:52 localstore.rdf
    -r--r--r-- 1 root root 287 2005-07-24 19:52 mimeTypes.rdf
    -r--r--r-- 1 root root 3287 2005-07-24 19:52 search.rdf


    rob@ubuntu:~$ ls -l /home/rob/mozprofile/foxnightly
    insgesamt 7064
    -r--r--r-- 1 rob rob 7137 2006-12-26 00:34 bookmarks.html
    -r--r--r-- 1 rob rob 153 2006-12-26 00:34 localstore.rdf
    -r--r--r-- 1 rob rob 287 2006-12-26 00:38 mimeTypes.rdf
    ...


    Mit Firefox 2.0.0.1 en-US:


    rob@ubuntu:~$ ls -l /opt/firefox/defaults/profile
    insgesamt 28
    -rw-r--r-- 1 root root 7138 2006-12-09 00:09 bookmarks.html
    drwxr-xr-x 2 root root 4096 2006-12-09 00:09 chrome
    -rw-r--r-- 1 root root 153 2006-12-09 00:09 localstore.rdf
    -rw-r--r-- 1 root root 287 2006-12-09 00:09 mimeTypes.rdf
    -rwxr-xr-x 1 root root 347 2006-12-09 00:09 prefs.js
    -rw-r--r-- 1 root root 3287 2006-12-09 00:09 search.rdf


    rob@ubuntu:~$ ls -l /home/rob/mozprofile/foxnightly
    insgesamt 7064
    -rw-r--r-- 1 rob rob 7165 2006-12-26 01:08 bookmarks.html
    -rw-r--r-- 1 rob rob 1919 2006-12-26 01:08 localstore.rdf
    -rw-r--r-- 1 rob rob 287 2006-12-26 01:08 mimeTypes.rdf
    ...

    Das Problem ist, dass ich den Bug 364599 zwar am 21.12.2006 gemeldet habe, aber der Bug immer noch den Status "UNCONFIRMED" besitzt und anscheinend auch noch niemand versucht hat den Fehler zu reproduzieren. Solange sich niemand um den Bug kümmert bringt auch die Existenz einer Bug-Meldung nichts.


    An anderen Bug-Meldungen sind mir bislang aufgefallen:
    https://bugzilla.mozilla.org/show_bug.cgi?id=364752
    https://bugzilla.mozilla.org/show_bug.cgi?id=364983


    Diese Bug-Meldungen sind leider aber auch alle "UNCONFIRMED".

    Bei mir hat folgender Workaround bei einer manuellen Installation von Firefox 2.0.0.1 de funktioniert:


    1. Firefox installieren und nicht! starten.
    2. Den Schreibschutz auf allen Dateien im Programmordner! "*\Mozilla Firefox\defaults\profile" aufheben.
    (Vorgehen in Windows XP: Eigenschaften des Ordners "*\Mozilla Firefox\defaults\profile" anzeigen lassen, das Attribut Schreibgeschützt abwählen und die Änderungen auch für alle Unterordner und Dateien übernehmen lassen.)
    3. Firefox starten, die nun neu erstellten Profildateien (insbesondere bookmarks.html und localstore.rdf) sollten jetzt ohne Schreibschutz sein.
    4. Falls schon ein Profil vorhanden ist, muss man zusätzlich den Schreibschutz auf auf den betroffenen Profildateien entfernen oder diese löschen und von Firefox neu erstellen lassen. Eventuell vorhandene Dateien bookmarks-("$Zahl").html und bookmarks.html.moztmp löschen.


    Der Workaround mit der Installation einer Vorgängerversion und dann das Update auf 2.0.0.1 sorgt dafür, dass die Profildateien durch die Vorgängerversion ohne Schreibschutz erstellt werden und dann nach dem Update weiterverwendet werden. Falls die betroffen Profildateien aber neu erstellt werden, z.B. in einem zweiten Profil, sind sie wieder schreibgeschützt.


    Mir kommt es so vor, als sei seit dem letzten Update die Anzahl von Threads mit Problemen, die wahrscheinlich auf schreibgeschützte Profildateien zurückzuführen sind, deutlich angestiegen. Ich denke deshalb immer noch, dass die deutsche Firefoxversion diesbezüglich einen Bug enthält.

    Bei mir ist auch das Problem aufgetreten, dass nach manueller Installation von Firefox 2.0.0.1 deutsch die Dateien bookmarks.html und localstore.rdf schreibgeschützt sind. Firefox speichert deshalb nicht die Fensteranordnung und erstellt mehrere durchnummerierte Lesezeichendateien im Profil. Dieses Verhalten konnte ich auf zwei Rechnern mehrfach reproduzieren und halte es deshalb für einen Bug in Firefox 2.0.0.1 deutsch.


    Anscheinend erzeugt Firefox einige Profildateien, darunter bookmarks.html und localstore.rdf, schreibgeschützt. Wenn diese Dateien schon vorhanden sind bleiben sie ohne Schreibschutz, der Fehler tritt also nur bei neu erzeugten Dateien auf. Die problematischen Dateien sind wohl alle Dateien im Programmordner *\Mozilla Firefox\defaults\profile, die Dateien sind dort schon schreibgeschützt und Firefox erzeugt diese Dateien dann auch in den Profilen schreibgeschützt. Wenn ich den Schreibschutz dort aufhebe werden die Dateien korrekt in den Profilen erzeugt.


    Das Problem konnte ich nur mit Firefox 2.0.0.1 de reproduzieren, mit Firefox 2.0 de, Firefox 2.0 en-US und Firefox 2.0.0.1 en-US gab es keine Probleme, die Dateien unter *\Mozilla Firefox\defaults\profile sind auch nicht schreibgeschützt.
    Dieses Problem habe ich als Bug gemeldet: https://bugzilla.mozilla.org/show_bug.cgi?id=364599 (mein Englisch ist leider nicht das Beste). Falls andere das Problem bestätigen können, halte ich es für einen ziemlich wichtigen Bug.

    Gerade getestet, der Eintrag funktioniert eigentlich, wird so auch auf diversen Seiten aufgeführt.


    Zitat von Nachtkappe

    habe jetzt im profilordner die datei "user.js" erstellt.


    in ihr steht wörtlich:
    user_pref("browser.cache.disk.parent_directory", "D:\\Cache Firefox")


    das habe ich 1:1 so rauskopiert.


    Dem Eintrag fehlt das Semikolon, der richtige Eintrag muß lauten:


    Zitat von Dr. Evil

    user_pref("browser.cache.disk.parent_directory", "D:\\Cache Firefox");


    Dann sollte der Eintrag auch in about:config (prefs.js) auftauchen.


    Viel Erfolg

    Die Warnung lässt sich über die Einstellung network.http.phishy-userpass-length beeinflussen:


    Zitat von <woltlab-metacode-marker data-name=

    " data-link="">

    network.http.phishy-userpass-length


    Integer


    A number between 0 and 255. Warn the user if we load an URL containing a userpass field (e.g., http://user:pass@example.com/) unless its length is less than this threshold. Default value is 1.


    Wenn man diesen Wert (Eintrag muss erst in about:config oder in der user.js angelegt werden) entsprechend erhöht, fällt die Warnung weg.

    Verfolge doch noch einmal die bisherigen Ansätze:



    Schreibschutz:


    Die Einstellungen der Symbolleiste werden in der Datei localstore.rdf im Profilordner gespeichert. Bitte noch einmal gezielt auf Schreibschutz überprüfen, allerdings unwahrscheinlich, da anscheinend bei Dir die Einstellungen über mehrere Sessions gespeichert werden.


    Erweiterungen, Themes:


    Du hast recht viele Erweiterungen (darunter die problematische Tabbrowser Extension), um diese als Problemquellen auszuschließen, ist es sinnvoll herauszufinden ob der nackte Firefox funktioniert.
    Dazu kannst Du den Safe Mode, oder (um völlig sicher zu sein) nochmal ein neues Profil benutzen.



    Solange Du nicht den nackten Firefox testest, bleibt es ein Gestochere im Dunkeln.

    Dazu passender Blogeintrag von Mike Connor, anscheinend gibt es doch Überlegungen ein Zonenmodell für Firefox einzuführen:


    Zitat von <woltlab-metacode-marker data-name=

    Mike Connor: More Firefox updates" data-link="">

    Another tough decision is “what features to try to get in for 1.1″ which came up in a lot of my discussions. There’s a proto-spec/proposal evolving here regarding a security zone implementation for Firefox. Right now, we’re scratching the surface on content/site controls, and in a fairly clunky and complex setup. I believe that we can use a zone-based system to simplify our site management, and lower the bar to users controlling their experience without excessive UI/interaction. Since Michiel van Leeuwen has done a great deal of work (not yet exposed UI-wise) with blocking scripts/objects(plugins)/stylesheets/etc we have a lot more power than we’re exposing, but another bunch of exception lists is not a viable answer.


    OT:
    Interessante Überlegungen zu IE7 von Rafael Ebron.

    Die Sygate Personal Firewall (Version 5.5 build 2710) benutze ich auch und bei mir funktioniert der Prüfsummencheck. In den Optionen habe ich keine Möglichkeiten gefunden diesen zu ändern, kann das Verhalten bei Dir also auch nicht verstehen.
    Bei Versionswechseln von Programmen muss man deren Zulässigkeit bestätigen und im Security-Log wird ein Eintrag erstellt:

    Zitat

    Auszug aus dem Eintrag:


    Security Type: Executable File Change Accepted


    Application has changed since the last time you opened it, process id: xxx
    Filename: D:\Programme\Mozilla Firefox\firefox.exe
    The change was allowed by user


    Mal ins Blaue geraten:
    -Firewall steht auf "Normal"?
    -Irgendwelche besonderen "Advanced Rules"?
    -Wenn Du die DLL-Authentifizierung aktiviert hast meckert Sygate doch andauernd, erhälst Du dort auch keine Meldungen (selbst wenn Du die gespeicherten Fingerprints löschst)?
    -Holzhammermethode: Hilft Neuinstallation mit neuester Version, davor Sygate-Programmordner löschen?


    Ihren Zweck (mehr Kontrolle über Programme mit Heimweh) erfüllt sie bei mir gut, mir fehlt aber eine Option im Sinne: "Alles blocken, außer eine Regel existiert".

    Beim Update werden keine Erweiterungen mitinstalliert. Eine unbemerkte Installation von Erweiterungen ist durch die Liste für berechtigte Websiten und die dreisekündige Verzögerung für den OK-Button eigentlich auch nicht möglich (wäre auch eine gefährliche Sicherheitslücke).


    Wenn man viele Erweiterungen ausprobiert, kann man aber schon mal die Übersicht verlieren. Vielleicht hast Du Flashblock vor längerer Zeit installiert, im Erweiterungsmanager deaktiviert und das Update hat es jetzt wieder aktiviert.

    Die Links in der Signatur und die eigene Website von Tyr0n finde ich problematisch. Die nichtssagenden Adressen h**p://hom.dl.ag/ und h**p://bifi.6x.to/ führen zu h**p://www.firstload.de/.
    Die Website und auch eine Suche nach Erfahrungsberichten zeigen, daß dieser Anbieter extrem unseriös ist (z.B. Telefonnr.: 0043 1 259 70 83).

    Im trunk Nightly von Gestern (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050324 Firefox/1.0+) funktioniert es nicht, die Final 1.0.2 ist mir beim gleichen Test abgestürzt.


    Das Drag und Drop Verhalten ist eine der wenigen Sachen die durch die neue Version geändert wurden, mal schauen was Bugzilla hergibt .

    Du kannst versuchen die Googlebar im Safe-Modus zu deinstallieren.


    Wenn das auch nicht hilft, hast Du wahrscheinlich ein beschädigtes Profil. Die sauberste Methode ist dann das Anlegen eines neuen Profils, Roadrunner hat das auf seiner Website sehr gut beschrieben.
    Zusätzlich zu den angegebenen Dateien kannst Du nach Bedarf auch
    formhistory.dat (Formulareinträge) und history.dat (Die Chronik) ins neue Profil kopieren.


    Wichtig: Wie beschrieben müssen Erweiterungen und Themes danach neu installiert werden, deshalb ist es sinnvoll diese immer erst auf der Festplatte zu speichern und dann zu installieren.


    Als Alternative zur Googlebar gibt es die Googlebar Lite, die eine schlankere und besser vorkonfigurierte Alternative sein soll.


    Nach welcher Methode hast Du eigentlich das Update gemacht?


    Viel Erfolg

    Bislang gibt es kein automatisches Update für Mac und Linux:


    Zitat von <woltlab-metacode-marker data-name=

    Asa Dotzler über das Update auf Firefox 1.0.1" data-link="">

    Oh, just a reminder, this is Windows only. If you're a Mac user or a Linux user, just head to the website and download there.