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“.

    Boersenfeger
    Ich weiß mein Text klingt ein bisschen wie die unzähligen Posts ala "Firefox ist völlig unbenutzbar, warum sieht das keiner !!1!!elf", das ist aber nicht meine Intention. Der Bug tritt nach meinen Versuchen für den Benutzer deutlich sichtbar nur bei sehr vielen Lesezeichen, einer großen Chronik und bei bestimmten URLs auf. Ich will explizit keinen Support, mich interessiert hauptsächlich ob jemand ähnliche Erfahrungen gemacht hat und ob der Bug mit den Schritten reproduzierbar ist oder nicht. Deshalb habe ich auch extra hier gepostet, der Bug ist mir zuerst im Trunk aufgefallen, ist dort noch sichtbar und die Schritte sind nur sinnvoll für jemanden der schon Erfahrung mit Builds hat (neues Profil etc.). Hier im Thread werden häufiger Erfahrungen und Bugs in Trunk-Builds geschildert, ein eigener Thread im Builds-Forum erschien mir nicht nötig.


    Aufgrund deiner Fragen bin ich mir nicht sicher ob du den Bug gelesen hast, ich habe wirklich versucht es gründlich zu testen. Getestet habe ich auf drei verschiedenen Rechnern mit 2* Windows XP mit Avast, Windows 7 mit MSSE und Ubuntu 8.04. Sicherheitsprogramme waren jeweils testweise an- und abgeschaltet. Neue Profile habe ich selbstverständlich ausprobiert, dabei hat sich eben gezeigt, dass der Bug nur unter bestimmten Umständen auftritt. Deshalb habe ich zwei Testdateien erstellt und auch ein neues Profil in Firefox 3.6 erstellt um dessen places.sqlite-Datei nach einiger Zeit wieder im Trunk zu testen. Twitter ist nicht die einzige URL bei der das auftritt (auch z.B. bei https://adblockplus.org/forum/), die Seiten lassen sich mit einer Default places.sqlite-Datei auch problemlos aufrufen, erst wenn die Chronik wieder eine bestimmte Größe erreicht hat wird das Problem wieder sichtbar.


    Mich würde einfach interessieren ob der Bug für andere mit den Schritten reproduzierbar ist oder nicht, falls nicht ist das für mich auch nicht schlimm. Manche Bugs sind schlecht reproduzierbar, das und ein seltenes Auftreten kann auch bei relativ schwerwiegenden Bugs dazu führen, dass sie lange unentdeckt bleiben (z.B. Bug 419170).

    Hallo,


    die Benutzung der Trunk-Builds und jetzt auch von Firefox 4 Rc 1 wird mir seit geraumer Zeit durch einen vermeintlichen Bug ziemlich verleidet. Den Bug habe ich vor längerer Zeit schon mal gemeldet (Bug 555292 - Minefield hangs on twitter.com), leider ist nicht viel daraus geworden. Ich hab in den Bug inzwischen schon einige Stunden investiert und konnte ihn auf mehreren Rechnern/ Betriebssystemen sicher reproduzieren, deshalb und auch aufgrund von Erfahrungen mit anderen Bugs glaube ich nicht, dass ich Geister sehe.
    Vielleicht hätte hier jemand kurz Zeit um zu versuchen ob er den Bug reproduzieren kann:


    1. Die places.sqlite Datei aus dem Anhang im Bug in ein leeres Profil kopieren
    2. Firefox starten und ein Programm zur Anzeige der Prozessorauslastung starten (z.B. Taskmanager)
    3. Die Twitter-Homepage aufrufen, z.B. in die Adressleiste twitter.com eingeben und Enter drücken
    4. Die Höhe und Dauer der Prozessauslastung beachten, ebenso die flüssige Bedienbarkeit der Benutzeroberfläche
    5. Schritt 3 wiederholen, auch mit neu laden, über Suchergebnisse der Adressleiste, etc.


    Bei mir führt das zu mehreren Sekunden mit 100% CPU und hakeliger bis komplett hängender Benutzeroberfläche. Vermutlich hat es mit twitter selbst nichts zu tun, es ist nur dort am auffälligsten bei mir.


    Vielen Dank im Voraus

    Zitat von angelheart

    Mich würde interessieren, ob Du tatsächlich, über das bei Dir erscheinende Einwahlfenster, auch eine Verbindung herstellen konntest?


    Ja, das hatte ich ein paar mal ausprobiert. Bei einem Versuch erschien das Verbindungsfenster allerdings doppelt.


    Zitat von universum123

    mich würde mal interessieren welche Version das war vor dem Fix


    Um den Beginn des Fehlers zu finden (regression range) habe ich die Trunk Nightlies durchgetestet, beim Build 2008-11-13-04-mozilla-central gings noch, beim darauffolgenden 2008-11-14-03-mozilla-central nicht mehr. Über die Änderungen dazwischen (Pushlog) bin ich auf Bug 454381 gekommen.

    Ich hab auch mal probiert das Problem mit einem über das Netzwerk angeschlossenen DSL-Modem und Einwahl über eine Breitbandverbindung zu reproduzieren. Das Verbindungsfenster erscheint bei mir nicht mehr seit dem Fix für Bug 454381 (Minefield Nightly brings up Dial-Up Login if a website is unavailable), Bug 465158 (Minefield Nightly fails to initiate dial-up login when using internet connection sharing) hat das Problem wohl in manchen Fällen behoben, aber nicht in diesem.


    Wenn ich die LAN-Verbindung deaktiviere erscheint bei mir das Verbindungsfenster, die Verbindung selbst klappt dann logischerweise aber nicht. Wie gewünscht funktioniert es wenn ich einen Haken bei "Anderen Benutzern im Netzwerk gestatten, die Internetverbindung dieses Computers zu benutzen" mache (Bug 465158). Bei mir erscheint das Verbindungsfenster je nach Einstellung entweder immer oder nie. Vielleicht wird durch die Netzwerkverbindung auf eine schon bestehende Verbindung geschlossen.

    Das liegt an den Microsummaries, man kann diese deaktivieren indem man per about:config "browser.microsummary.enabled" auf "false" setzt.


    Unter Firefox 3 ist das ganze noch nerviger, dort werden die Lesezeichen-Eigenschaften direkt angezeigt, dass heißt die Microsummeries werden schon beim auswählen eines Lesezeichens in der Bibliothek abgefragt.


    Bug 434712 – Network connection and Send something when edit bookmarks.

    Dass Seiten, für die ein Lesezeichen existiert, auch nach dem Löschen der Chronik als eingetippt markiert sind würde ich als Bug einstufen. Es gibt mehrere Möglichkeiten warum solche Seiten als eingetippt markiert wurden:


    1. Url eines Lesezeichens in die Adressleiste eingegeben
    2. Schon mal eingegebene Seite als Lesezeichen hinzugefügt
    3. Lesezeichen bei der Suche in der Adressleiste ausgewählt oder in der Ausklappliste der Adressleiste (vor browser.urlbar.matchOnlyTyped auf true)
    4. ?


    Man könnte aber immer noch die places.sqlite Datenbank manuell bearbeiten und in der Tabelle moz_places für diese Seiten typed auf 0 setzen. Damit auch die Lesezeichen aus Fall 3 nicht mehr auftauchen, müsste man zusätzlich diese Seiten aus der inputhistory (adaptives Lernen) entfernen. Vor solchen Aktionen sollte man ein Backup der places.sqlite Datei anlegen.


    Um wirklich alle Lesezeichen von der Suche auszuschließen bräuchte man Bug 395161 und Bug 424557 (vielleicht in Firefox 3.1), oder eine entsprechende Erweiterung.


    Edit:
    Du könntest die folgenden beiden Befehle verwenden, z.B. im SQLite Database Browser. Ich habe beide Befehle kurz getestet, aber ich kann natürlich nicht garantieren, dass es keine Problem gibt. Deshalb unbedingt vorher ein Backup machen!


    typed für Lesezeichen auf 0 setzten:

    SQL
    UPDATE moz_places SET typed = 0
    WHERE typed = 1
    AND id IN (SELECT h.id FROM moz_places h WHERE EXISTS
    (SELECT b.id FROM moz_bookmarks b WHERE b.fk = h.id));


    Lesezeichen aus der inputhistory löschen:

    SQL
    DELETE FROM moz_inputhistory
    WHERE place_id IN (SELECT h.id FROM moz_places h WHERE EXISTS
    (SELECT b.id FROM moz_bookmarks b WHERE b.fk = h.id));

    Ich hab noch mal das aktuelle Opera-Build ausprobiert und der Speicherbedarf der Volltextsuche ist tatsächlich nicht zu vernachlässigen. Mein vps-Verzeichnis ist 34,6MB groß bei einer Chronik von 336 Seiten (Zeilenanzahl der global.dat durch 4), das entspräche 51MB pro 500 Seiten.
    Mir ist auch aufgefallen, dass Opera die Anzahl der Seiten in der Chronik hart auf 10000 begrenzt, der Wert lässt sich in der opera6.ini nicht dauerhaft höher einstellen (Standardwert: 500 Seiten, Standardwert Firefox: 40000 Seiten).

    Die Idee ist jedenfalls nichts komplett neues, dieser Meta-Bug und die dort verlinkten Bugs sind teilweise einige Jahre alt. Für Places in Firefox 3 war die Suche im kompletten Textinhalt angedacht, siehe z.B. Link_1 und Link_2 von Anfang 2007, aber nur mit geringer Priorität. Places sollte auch mal in Firefox 2 integriert werden, da habe ich auf die Schnelle aber nichts über die Suche im kompletten Textinhalt gefunden.
    Bei Opera war dieses Feature in der ersten öffentlich Alpha aus dem September 2007 enthalten.
    Wer ein bestimmtes Feature erfunden, eingeführt oder populär gemacht hat dürfte teilweise schwierig zu bestimmen sein, das gegenseitige Aufgreifen von guten Ideen dient dem allgemeinen Fortschritt. Deshalb finde ich es interessanter die aktuellen Implementierungen zu vergleichen.


    Firefox 3 benutze ich jetzt schon einige Monate als Standardbrowser, Opera teste ich immer mal wieder kurz an. Man kann beide Varianten der Suche in der Adressleiste schlecht mit einer Checkliste vergleichen, teilweise liegen die Unterschiede im Detail. Mein groben Eindrücke sind:


    Firefox:
    - gute Gewichtung der Suchergebnisse
    - adaptives Lernen
    - Lesezeichen und Chronik gemischt in den Suchergebnissen
    - Suche im kompletten Titel und der kompletten URL
    - teilweise Peformance-Probleme


    Opera (Fehler bitte verbessern):
    - Suche im kompletten Textinhalt
    - zuerst Lesezeichen, dann eingegebene Adressen, dann Chronik in den Suchergebnissen
    - bei Lesezeichen wird nur die Domain der Url durchsucht (fällt auf bei unbesuchten Lesezeichen)
    - sehr schnell (nur mit kleiner Chronik getestet)


    Die Suche im kompletten Textinhalt scheint einiges an Speicherplatz zu benötigen, ein Opera-Mitarbeiter hat als Anhaltswert 10 MB pro 500 Seiten angegeben. Wie gut sich das mit einer großen Chronik verträgt wird sicher interessant (Beispiel: Eine Chronik über 90 Tage mit 200 Seitenbesuchen täglich entspräche ungefähr 360MB). Auch die Gewichtung der Suchergebnisse muss sehr gut funktionieren, sonst sind Suchbegriffe wie Firefox oder Linux völlig nutzlos.


    Es wird spannend zu sehen wie gut sich beide Varianten in der Praxis bewähren werden, für mich ist die Suche in Firefox 3 schon mal ein riesiger Fortschritt gegenüber der 2er Version. Leider haben es Bug 395161 und Bug 424557 nicht mehr in Firefox 3 geschafft, damit hätte man, falls gewünscht, auch ein ähnliches Verhalten wie in Firefox 2 einstellen können.

    Anscheinend kann man noch deutlich falscher darüber berichten, der Teil über Firefox 3 in [url=http://www.spiegel.de/netzwelt/web/0,1518,554034,00.html]diesem Spiegel Online Artikel[/url] ist wohl völlig recherchefrei entstanden.


    Zitat von Firefox 3 RC1 ist draußen

    So mancher stößt sich an der Datensammelwut, die der Browser bei jedem Update und bei jeder Versionsüberprüfung an den Tag legt. Dann nämlich telefoniert er auch nach Hause, um Daten zum Nutzerverhalten, zum Beispiel zu besuchten Seiten, an die Zentrale weiterzugeben. Diese kommerzielle Auswertung personenbezogener Daten wäre vor Jahren wohl noch nicht denkbar gewesen - nicht bei den Verantwortlichen der Mozilla Foundation.


    Firefox muss für ein funktionsfähiges automatische Updatesystem nun mal "nach Hause telefonieren" und übermittelt dabei bestimmte Daten (z.B. Produkt, Versionsnummer, Sprache, Update-Channel), diese sind aber für das Updatesystem selbst notwendig. Mozilla hat kein Geheimnis daraus gemacht, dass diese Daten ausgewertet werden um z.B. zu bestimmen wie schnell auf eine neue Version aktualisiert wird (siehe Blog of Metrics). Daran sehe ich allerdings nichts verwerfliches.


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

    Mozilla & Firefox Market Share" data-link="">

    Here’s how we get to that number. Firefox uses a system that we call AUS (Application Update Service) to keep itself up-to-date with security patches & such. Around once a day, Firefox will ping Mozilla servers to see if there’s a new update available, and if there is, it’ll present an option to users to download and install it. (AUS really deserves a longer posting — the ping is non-identifiable, respecting user privacy, and is one of the major reasons that the Firefox user base, as large as it is, is nearly all using the most recent, patched version at any given time.)


    We count those pings, categorized by language version of Firefox, so we have a rough indication for any given day about how many instances of Firefox were running.


    Wenn jemand tatsächlich glaubt aktuelle Firefox-Versionen würden die besuchten Seiten übermitteln, dann soll er es bitte auch belegen, Firefox ist immerhin Open Source.


    Edit:
    Sehr lesenswerter Blog-Eintrag von Robert Accettura:
    http://robert.accettura.com/bl…9/no-secret-data-project/