Entwicklung Firefox

Mal wieder ein Kurzüberblick [1] .

[1] http://www.squarefree.com/burningedge/20…9-trunk-builds/

... ist erfolgt,
Der Kandidat liegt nun QA vor.

UA: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9 ID:20110110191547

Empfinde ich für gut und richtig [1], [2]. Das betrifft zum 1-nen ein wesentliches Feature der 4-ten Generation des Browsers und ist der Stabilität geschuldet. Und ich hoffe, dass diese Ergebnisse noch in die Final einfließen.

Hier wurde wurde auch mit Treiber- Versionen experimentiert. Momentan bin ich ebenfalls seit ca. 2 Monaten bei Vers. 260.99. Und habe damit bei allen entsprechend gesetzten HW- Beschleunigungsschaltern keine (wesentlichen!) Probleme.
Mit meiner vorherigen Version (257.21) war ein vernünftiges Arbeiten nur mit

user_pref("gfx.direct2d.disabled", true);

(Default in den Nightlies *false*) möglich.

Schauen wir mal!

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=582053
[2] https://bugzilla.mozilla.org/show_bug.cgi?i…=mozilla-search

Zitat von Estartu

- Müsste dann der Minefield nicht langsam in die b10pre-Phase übergehen?

...über einen günstigen (günstigeren) ZP könnte man diskutieren.
http://hg.mozilla.org/mozilla-central/rev/bcab2d6652cb

...na dann - viel Spass [1].
UA: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110112 Firefox/4.0b10pre ID:20110112033217

[1] https://www.camp-firefox.de/forum/viewtopi…db7c1c4#p699071

Heute war mal wieder ein Win- Building erfolgt und ein AUS- Abruf erfolgreich.
Aber in der jetzigen Beta- Phase wird mal wohl kaum (zumal für Windows) mit einer entsprechenden Auslieferung am Finaltag rechnen können.

UA: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b10pre) Gecko/20110112 Firefox/4.0b10pre ID:20110112074539

Vorab: Safe Mode + Vacuum ist hier nicht wirklich hilfreich!

Man müsste vllt. dazu in den Urschleim zurück. Möchte ich mir sparen. Meine Worte:

Mozilla hat auf SQLITE [1], [2] umgestellt /stellt noch um. Man konnte diese Datenbänke zunächst (und immer noch) mit dem Vacuum-Befehl *defragmentieren*. Mit der Einarbeitung des Bug 541373 [3] sollte das definiert in Zeitabständen aus Firefox heraus selbst erfolgen. Jedoch scheint dies nicht so zu funktionieren. Oder anders gesagt - Mozilla hat für das *Defragmentieren* dieser Dateien, speziell auch der places.sqlite noch keine abschließende Lösung. Der Bug 538493 [4] ist zwar SM, aber er trifft den gleichen *Unterbau*.

Mein Fazit: Ich denke, dass Mozilla unter diesen Aspekten momentan eine sichere Größe dieser Datei vorgibt. Eine Quelle für den Beleg dieser These kann ich mom. und auf die Schnelle nicht angeben. Der Vacuum- Befehl kann scheinbar eine komprimierte Datei dadurch nicht wie gewünscht zurück schreiben.

[1] http://de.wikipedia.org/wiki/SQLite
[2] http://www.sqlite.org/lang.html
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=541373
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=538493

Zitat von viPer20

seh ich auch so, meine ursprüngliche places.sqlite hat 10MB, im Lauf der Zeit (je nach Größe der Chronik) wächst sie an auf den doppelten bzw. dreifachen Wert, 20MB, 30MB..,

... das ist nicht dass, was seipe meinte.

Dieser Vorgang ist *normal* und kann mit vacuum wieder - und eben - auf die vorgegebene Größe *defragmentiert* werden. (Oder wie es früher hieß *reorganisiert* werden.) Das ist ein üblicher Prozess bei DB- Systemen und hängt damit zusammen, dass *erfasst*, *geändert* und *gelöscht* wird. Und natürlich müssen Indexe ebenfalls ab und an neu geschrieben /zugeordnet werden.

Das kann *physisch* Vacuum realisieren. D.h., die Datenbank wird gelesen, entsprechend der Markierungen geändert und zurück geschrieben.

Das hat aber nichts mit der vermeintlich festen Vorgabe zu tun!

Zitat von viPer20

- mit dem Ergebniss das Fx erstens schneller startet und zweitens die Chronik verzögerungsfrei aufgerufen wird, seh ich das richtig?

Minimal und unterstützend - Ja!

Zitat von viPer20

- find es halt schade das man da jedesmal selbst "Hand anlegen" muß, und nicht automatisch passiert beim löschen der Chronik

Ich hatte es w.o. versucht mit meinen Worten zu erläutern.
Das *Löschen* ist zunächst ein psychischer Vorgang und gipfelt ggf. in einer Markierung². Löschen bedeutet nicht *Radiergummi* .
Dazu ist eben dann Vacuum da!

Ja - und es gab und gibt sicherlich Bestrebungen den User von diesen Vorgang in Perioden zu entlasten
(s.d.a. Beitrag #1515 und Bug 541373).

² Nur um vorzubeugen. Wenn etwas neu erfasst wird und ES ist passend zu einer derartigen Markierung, dann erfolgt natürlich ein Überschreiben.

Ich hoffe, dass einer der Nightly- User mir einen Hinweis geben kann oder meine Beobachtung bestätigt.
Voraussetzung: Keine Tab-Extension oder Session-Extension.

Hier wird mit Startup-Option *Show my home page* (about:blank) gearbeitet. Mit Beenden des Browsers erfolgt das Registrieren der Session (Save and Quit) für einen Restart. Ich habe nun meine sessionstore.js aufgeteilt in 4 Tab-Gruppen (TabCandy). Ein Restart erfolgt bei dieser Einstellung mit der zuletzt offenen Gruppe, wobei alle anderen Gruppen ebenfalls noch vorhanden sind und in den Fokus geholt werden können. Das soll auch so sein.

In der Profil-Struktur und der bisher kaum /nicht vorhandenen Dokumentation habe ich noch keinen Hinweis auf ein zur sessionstore.js abweichenden Hinterlegungsort gefunden.

Nun das Problem.
Wenn ich nun die Option *Bookmark All Tabs...* nutze, wurden hier ohne TabCandy die offenen Tabs als Bookmarks in einen zu benennenden Ordner abgelegt. Mit TabCandy wird mir nur die aktuell im Zugriff befindliche Gruppe abgelegt. Würde ich also diesen Bookmarks-Ordner nutzen, wären die anderen Gruppen verloren.

Wenn dem so ist, dann ist das für mich unlogisch!

Kann dazu wer was sagen? :wink:

»»»»»»»»»»»»»»»»»» ««««««««««««««««««««
Edit - Dafür gibt es keinen Flag + keine Lobby!
https://bugzilla.mozilla.org/show_bug.cgi?id=604963

und *abgeschwächt* - auch da Probleme ohne Lobby
https://bugzilla.mozilla.org/show_bug.cgi?id=621649

na fein! Hauptsache die Pixel werden geschubst. Elemente zum Erhalten von Arbeitsständen scheinen nicht von Bedeutung zu sein!