Entwicklung Firefox

Im Inbound-Build ist das SPDY Protocol (Google Chrome [1]) bereits implementiert [2]. Noch deaktiv!
Falls jemand das Inbound-Build damit testen möchte, dann sollte er den Schalter (comment #174) setzen. :lol:

Vllt. für interessierte User eine gute DE-Erläuterung zu diesem Protocol - [3]. Chrome (Beta-) User werden es kennen! :wink:

UA: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:11.0a1) Gecko/20111202 Firefox/11.0a1 ID:20111202040356
Changelog: http://hg.mozilla.org/integration/mo…ev/93c850b9f00f

[1] http://dev.chromium.org/spdy/spdy-protocol
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=spdy
[3] http://www.golem.de/1104/82657.html

...und nun auch im Nightly (deaktiv), guckst du:

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

UA: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111204 Firefox/11.0a1 ID:20111204031102
Pushlog: http://hg.mozilla.org/mozilla-centra…ge=c2102c45c8da

me,
Nachfragen: Was ist ein Arbeitsprofil? Ein eingestelltes und ergänztes Profil? Und wie speicherst du in diesem *Arbeitsprofil* die Session?

Hier (ohne Tab-Extension, mit Start-Page als Startup und mit Sessionstore über *save and quit*) gab es 0 Zerstörung der Defaultdatei sessionstore.js mit dem gestrigen und heutigen Build und einem eingestellten Profil. Konnte dazu auch im Net nichts finden...

UA: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111205 Firefox/11.0a1 ID:20111205040315

Vllt. nutzt diese Extension irgend wie optional die sessionstore.js?! K.A.
Teste doch mal diese spezielle Build-ID mit dieser Extension separat. Und dabei vllt. auch mal mit wechselnden optionalen Einstellungen!

Zitat von TheRave

- Gabs denn mit Build vom 4.12 Änderungen die mit Tabs oder Sessionstore zu tun hatten?

Ich denke, dass me verlässlich die Ursache einer Extension (einem Pre-Release) zuordnen konnte. Deshalb denke ich, dass es nur über den weiter oben beschrieben Weg möglich ist, eine optionale Einstellungskombination zu finden, bei welcher die sessionstore.js die Hände hebt. Und dann wäre immer noch dieses Drittprogramm ursächlich. Ob me diesen Aufwand bei einer nicht finalen Extension treiben möchte... :wink:

Sessionstore.
Zunächst steht nach meiner Kenntnis dieser Komplex Sessionstore /Session-Restore in Verbindung mit der Funktionalität von BarTabs auf der Matte [1]. Jedoch können hier keine derartigen Verluste bis Dato auf diese Arbeiten zurückgeführt werden.

Builds vom 20111204.
Wie ich weiter oben bereits angedeutet hatte, habe ich auch nichts finden können. Aber bekanntlich können mehr Augen oftmals auch mehr sehen.

Nun wird es aber präzise :wink: . Ich weiß, dass me auch das 64-Bit nutzt. Bei welchen Build (32- od. 64-Bit) das konkrete Profilverhalten bei ihm auftrat, weiß ich nicht. Die Changelogs sind unterschiedlich.

Changelog 64-Bit: http://hg.mozilla.org/mozilla-central/rev/78de2c2bdad5
Changelog 32-Bit: http://hg.mozilla.org/mozilla-central/rev/c2102c45c8da

[1] https://www.camp-firefox.de/forum/viewtopi…5f73767#p767041

Zitat von MaximaleEleganz

- Nein, der Aufwand ist mir zu hoch!

Klar!
Ist verständlich und hatte ich mir schon gedacht. :wink:

Zitat von MaximaleEleganz

- Ich nutze ausschließlich die 64-Bit-Version.

Hatte ich geahnt; aber konnte korrekterweise nicht davon ausgehen.
Zumal ich mir auch die x86- Version zukommen lass!

//
Ich erlaube mir dir noch eine restliche frohe Adventszeit zu wünschen!

... ich weiß. :lol:
Ich kann dir auch den /die Pushlog(s) verlinken!

Bitta schon:
32 Bit: http://hg.mozilla.org/mozilla-centra…ge=c2102c45c8da
64 Bit: http://hg.mozilla.org/mozilla-centra…ge=78de2c2bdad5

PS. Ich denke, der Changelog ist besser für das schnelle Querlesen! :wink:

me,
da sind wir ggf. da, wo ich meinte, dass ich der sessionstore.js mit dem jetzigen Umfang (auch TabCandy) bei alter Struktur und Pflege nicht mehr traue! Es kann also Zufall sein, dass diese Profildatei genau beim Überstreifen dieses Builds die Hufe hob!

PS. Die heutigen Builds haben es aber auch in sich. :mrgreen: Hier zumindest die 64-Bit- Variante!

Im MZF ist man der Meinung, dass die Crashes durch Stylish oder dem Aufruf des Memory-Tableaus begünstigt würden [1]. Beides kann ich hier soo nicht bestätigen. Das Memory-Tableau in der Sidebar lässt den Browser stehen. Das Memory-Tableau als Tab - Crash. Stylish aktiv - Crash; deaktiv - Crash.

Ja - der Browser crashed hier mit einem Clean-Profil! :lol: [2]
Irgend wie nicht zuordenbar. Auch die Signatur ist nicht bei allen Crashes gleich.

Bin heute auf UX 64-Bit umgestiegen. Mal schauen...

UA: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:11.0a1) Gecko/20111207 Firefox/11.0a1 ID:20111207040255
Pushlog: https://hg.mozilla.org/projects/ux/pu…ge=7af6996087cd

[1] http://forums.mozillazine.org/viewtopic.php?…a6fb4#p11536649
[2] https://crash-stats.mozilla.com/report/index/b…e0-1872a2111207

http://www.squarefree.com/burningedge/20…7-trunk-builds/

Zitat von pcinfarkt

- Im MZF ist man der Meinung, dass die Crashes durch Stylish oder dem Aufruf des Memory-Tableaus begünstigt würden [1]. Beides kann ich hier soo nicht bestätigen. Das Memory-Tableau in der Sidebar lässt den Browser stehen. Das Memory-Tableau als Tab - Crash. Stylish aktiv - Crash; deaktiv - Crash.

Ja - der Browser crashed hier mit einem Clean-Profil! :lol: [2]
Irgend wie nicht zuordenbar. Auch die Signatur ist nicht bei allen Crashes gleich.

Die Crash-Ursache *scheint* (toi, toi, toi) mit dem heutigen Inbound-Build im Patch-Test behoben. Hier steht dieses 64-Bit-Build schon ca. ~1¼ h ( ).

UA: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:11.0a1) Gecko/20111209 Firefox/11.0a1 ID:20111209040309
Changelog (Inbound): http://hg.mozilla.org/integration/mo…ev/33ee84f7705f
Pushlog: http://hg.mozilla.org/integration/mo…ge=33ee84f7705f