Entwicklung Firefox

Sehe ich genauso.
Ist sowieso nur ein relativ aufwendiger augenscheinlicher Effekt. :wink:

Und wenn man den Browser-Cache vorhält nicht erforderlich...

Zitat von klink

- Ich habe den Disk-Cache genau wegen diesem Verhalten abgeschaltet, da brauche ich auch kein thumbnail mit so einem Verhalten.

...wobei dies nicht zwingend notwendig wäre.
Zumal sich dann solche Fragen [1] - auch wenn es da einen anderen Zusammenhang gab [2] - gänzlich nicht mehr stellen.

[1] https://www.camp-firefox.de/forum/viewtopi…003d96f#p779240
[2] https://www.camp-firefox.de/forum/viewtopi…003d96f#p789234

Namoroka-Update!
Schon mal sowas gesehen?

[Blockierte Grafik: http://www.img-teufel.de/uploads/WS265bdd253dcpng.png]

An und für sich gibt es dafür eine ganz simple Erklärung!
Jedoch steckt die dafür verantwortliche Ursache scheinbar auch in anderen Produkt-Entwicklungen von Mozilla...

Möglicherweise gibt es Nutzer der Entwicklungsbuilds, welche aus diversen Gründen bspw. in der user.js eine abweichende Wertzuweisung für die Preference [1]

browser.identity.ssl_domain_display

haben. Diese Preference wird mit der gestrigen Ausgabe des Trunkbuilds nicht mehr supported [2].

Build from Changeset: http://hg.mozilla.org/mozilla-central/rev/448f554f6acb

[1] http://kb.mozillazine.org/Browser.identi…_domain_display
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=748385

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

" data-link="">

- Meta-Bug 718011 - [meta] Move preferences from a window/sheet to in-content

In der heutigen m-i- Build- Ausgabe ist das im UX und in try-Builds getestete /vorgestellte Feature InContent-Preferences [1] *gelandet*. Das Feature ist implementiert und per Default noch inaktiv geschaltet. Das bezieht sich nicht auf die Nutzbarkeit bei Aktivierung [Abb.].

Möglicherweise steht damit eine zeitnahe Übernahme in das m-c- Build bevor...

[Blockierte Grafik: http://www.IMG-Teufel.de/thumbs/KT1297c9e4db17png.png]

UA: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120509040217
Build from Changeset: http://hg.mozilla.org/integration/mo…ev/15a028a333d2

[1] https://wiki.mozilla.org/In-content_preferences

Für Interessenten.

Das finde ich gut. Hier [1] wird nicht nur die Arbeit /der Stand und bisher noch offenen Verbesserungen vorgestellt, sondern auch die 4 daran massgeblich beteiligten Studenten. Nach meiner Kenntnis des Prozessses war Jon Rietveld der engagierteste /federführend.

[1] http://msujaws.wordpress.com/2012/05/10/in-…irefox-nightly/

Zitat von seipe

- Wenn ich seit ein paar Tagen Nightly aktualisiere [...] dann jedesmal die komplette Datei heruntergeladen. Kann das jemand von Euch bestätigen?

WFM
Hier keine Probleme mit dem inkrementelle Update. Für das Einspielen eines Komplett-Updates gibt es zumindest auch bekannte Gründe.

Zitat von seipe

- Konnte jetzt beobachten, dass sich bei geschlossenem Nightly im Profilordner >parent lock< nicht löscht. Hängt es eventuell damit zusammen?

Nein.
Einen Zusammenhang zwischen der permanenten parent.lock (ab v13) und dem Einspiel eines Komplett-MAR sollte es nicht geben.
Die *Schlachtung* einer weiteren *heiligen* Mozilla-Kuh hat andere Gründe. Meine Worte. Es geht dabei im weitesten Sinne um das Exit /Restart- Verhalten, vor allem dem (der Erfassung) des Start-Crash und tangiert auch das Safe Mode- Verhalten (Start).

...ist mir letztens bei diversen Tests aufgefallen. :wink:

Der Schalter (optionale Einstellung bzgl. des Erlaubens der seiteneigenen Farben)

browser.display.use_document_colors

hat per Default den Boolean-Wert *true*. Wenn dieser in der aktuellen Alpha 1(v15), 2(v14) und in der Beta (v13) auf *false* gekippt wird, verschwinden die Thumbnails von der NewTabPage. Es bleiben nur die Rahmen mit den Bezeichnungen der gewählten Seiten über. Einen Zusammenhang zw. Thumbnails + Webseitenfarben sehe ich eigentlich nicht zwingend ...

Wenn man das Feature in der aktuellen Final der Rapid-Releases (v12) aktiviert - also nur die Implementation des Features testet - bleiben die Thumbnails bei Wertveränderung des obigen Schalters erhalten. Ich denke, dass sich da etwas durch Rückschreibung in das Profil und der Handhabung der Bildchen (als Hintergrund) eingeschlichen hat.

UA: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120516030515

=================
Edit --- das fiel auch anderen auf
Bug 737877 - [New Tab Page] thumbnails disappear with browser.display.use_document_colors=false

Die Entwicklung der Rapid-Releases geht auch mit Anpassungen des UA einher [1]. Im http://1.HJ/2012 erfolgte zumindest bei der Alpha 1 der Mozille erneut eine Präzisierung. Das bisher ausgewiesene Gecko-Datum

Final ¹): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0 ID:20120420145725
Beta ¹): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0 ID:20120509070325
Alpha 2: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120516 Firefox/14.0a2 ID:20120516042006

wurde durch die Gecko-*Version* ersetzt [2].

Alpha 1: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120516030515

¹) Final + Beta mit bekanntem Freeze UA Build-ID (Bug 591537)

[1] https://www.camp-firefox.de/forum/viewtopi…9046978#p702398
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=588909