[url]ftp://ftp.mozilla.org//pub/firefox/releases/6.0/mac/de/Firefox%206.0.dmg[/url]
befindet sich schon auf den Mozilla Servern

Hm - kein Vollbildmodus, kein Zurückspringen am Seitenende, kein Zurück per Geste, keine offensichtlichen Änderungen, im Vergleich zu Safari ruckelndes Scrolling. Dann halt weiter Safari.

ruckelt echt, und zwar nicht wenig!

Die grossen Versionssprünge in der kurzen Zeit sind furchtbar. Die ganzen AddOns müssen wieder angepasst werden und die 7er ist auch schon in der Pipeline.

LoMacs:

Anpassungen und Änderungen speziell für Lion sind erst mit FF7 und FF8 zu erwarten, da ist man schon dabei, entspr. Patches/Änderungen für die Nighlies gibt es schon. Dass Safari auf diesem Lion-spezifischen Terrain einen zeitlichen Vorsprung hat, dürfte in der Natur der Sache liegen.

Keine Ahnung, was Du damit meinst.

Nicht damit befasst. Kann da keine Aussage zu treffen.

Müssen Änderungen immer offensichtlich sein?

Mozilla Firefox 6: Release Notes:

Ich denke mal, die Liste der gefixten Bugs und neu hinzugekommenen Features ist jedenfalls alles andere als kurz:

Mozilla Firefox 6: Fixed Bugs:

Kann zumindest ich nicht bestätigen. Beispiel?

ackerratte:

Zumindest bei mir ruckelt nix. Hast Du ein Beispiel (URL?) parat, wo es bei Dir ruckelt?
Evtl. irgendein Add-On installiert bzw. aktiviert, das diesbzgl. vielleicht nicht ganz rund läuft oder/und Ressourcen verbrät?

atomboy:

Inwiefern sind die furchtbar? Du bekommst alle 6 Wochen ein stabiles Browser-Update. hat vorher länger gedauert. Und ob dieses Update nun 4.schlagmichtot heißt oder 5.0, 6.0 etc. pp., ist vor diesem Hintergrund ja wohl völlig nebensächlich. Der Rest ist reine Psychologie und Gewöhnung: "Watt der Bauer nich kennt, datt frisst er nich..."

Alle Add-Ons? Nein. Micht alle. Zunehmend weniger.
Müssen sie nicht, wenn sie mit Mozillas neuem JetPack Add-On-SDK gebaut sind.
Außerdem gibt's den Add-on Compatibility Reporter , mit dem kannst Du selber jedes einzelne Add-On auf aktiv schalten, selbst wenn dessen Versionsstring sagt, dass es mit Deiner Browser-version nicht zusammenpasst. Und Du kannst mit einem Mausklick dem betreffenden Entwickler bzw. Mozilla das Signal zusenden "Funktioniert" oder "Funktioniert nicht".

Außerdem hat Mozilla , was addons.mozilla.org angeht, dort die Zügel zudem etwas gestrafft. Die Zügel gegenüber den Add-On-Entwicklern. Indem dort nur dann Add-Ons hochgeladen werden dürfen mit einem Versionsstring genau passend zur gerade aktuellen Firefox-Version. Add-Ons, die dem diesbzgl. vorgreifen durch Wildcards (*), werden abgeblockt. So werden die Entwickler der Add-Ons angehalten, ihre Erweiterungen regelmäßig zu pflegen und zu überprüfen, ob sie denn tatsächlich sauber ihren Dienst tun, statt sie monatelang verrotten zu lassen. Im Endeffekt: Vorteil für den Nutzer, weil unterm Strich hochwertigere und dem aktuellen Stand der Dinge angepassten Add-Ons dabei rauskommen und weniger "Karteileichen" herumliegen.

So wie FF8 auch schon in Gestalt der Nightlies in der Pipeline ist. Und ab kommenden Dienstag, wenn FF6 offiziell released wird, rückt dann alles eine weitere Stelle vor: Aurora (FF7) wird Beta (Release Candidate), Nightly (derzeit FF8) wird Aurora, und in den Nightly-Channel wird dann anzunehmenderweise das kommen, was später dann FF9 werden wird.

Und wo ist jetzt für Dich als Anwender das große Problem? Alle 6 Wochen bekommst Du ein neues, stabiles Firefox Release. Ist doch toll! Freu' Dich doch drauf! Ist doch völlig egal, wie das heißt bzw. welche Versionsnummer es konkret trägt. Hauptsache, es ist stabil und schnell. Und das ist bisher jedenfalls der Fall.

Und mit dem in 6 Wochen kommenden FF7 wird auch nochmal ein ganz gehöriger Schub nach vorne getätigt , weil man es wohl geschafft hat, Firefox 50% weniger Speicher verwenden zu lassen bzw. deutlich intelligenter und ressourcenschonender mit vorhandenem RAM-Speicher umzugehen (in FF6 hat man schon ein wenig damit angefangen: ) und diesen früher wieder freigeben (Garbage Collection) als bisherige FF und sogar auch die Browser der Konkurrenz -- gerade in Fällen, wo viele Browser-Tabs offen sind und/oder geschlossen werden (wo sich bisher alle Browser ja durchaus dick aufblähen im RAM. Gerade auch Safari).

Zurück per Geste geht (wie schon in FF5) wenn man die geste fürs seite wischen in den systemeinstellungen auf Drei finger fürs touchpad stellt. Neuerungen wie Vollbild, Tabs Gruppieren (eine art expose der geöffneten tabs) verbergen sich z.B. wenn man für die symbolleiste mal anpassen wählt ^^. Macht zwar kein Lion-like extra Space fürs Vollbild - aber mehr Vollbild geht ansonsten auch damit nicht ^^

Den ganzen Krempel hatte doch (fast) jeder andere Browser lange vor Safari. Da fragt man sich doch, warum du überhaupt Safari benutzt
Blödsinn

Das bezieht sich aber alles nur auf Java Script Geschichten.
Zu sagen Firefox 7 wird pauschal 50% weniger Speicher benötigen ist Quatsch. Wenn man nur auf aufwendigen JS Seiten unterwegs ist, mag es anderseits aber auch noch besser werden bzw. weniger verbrauchen - ist aber dann doch eher theoretischer Natur.

Wer sich über Lion-Anpassungen informieren will:
Die Lion Vor-Zurückgesten sind z.B. seit heute in den 7er Testversionen. Optische Lion-Anpassungen sind z.B. seit einigen Tagen in den 8er Testversionen drin. Dank der schnellen Versionswechsel ja dann alles in ein paar Wochen auch in den finalen Versionen ..

Aronnax:

Ja und nein. Die Links, die ich dazu gepostet habe, beziehen sich vor allem auf JavaScript. Doch der ganze Optimierungsprozess bzgl. Performance /Memshrink , Blog dazu: , umfasst alle möglichen Komponenten von Firefox und nicht nur JavaScript. JavaScript nimmt da sicher einen nicht unerheblichen Teil ein, ist aber nicht die einzige Ecke, die man diesbzgl. beackert. Alles, was irgendwie Speicher verbraucht (u.a. eben auch JavaScript) oder Ladezeit bedeutet -- die komplette interne Organisation des Firefox-Browsers -- wird da im Rahmen des Performance/MemShrink-Projektes derzeit angegangen, gestrafft und optimiert, es gibt da im Grunde keinen Bereich des Browsers, der diesbzgl. von diesen Optimierungen ausgenommen bzw. davon nicht betroffen ist.

Bzgl. der 50%-Aussage stütze ich mich u.a. auf diesen Blogeintrag des Verantwortlichen:

Nicholas Nethercote: Firefox 7 is lean and fast :

Damit meint er wohl, dass die sichtbare Website am Seitenende etwas nach oben »springt« und darunter die Gewebe-Struktur zum Vorschein kommt. Der selbe Effekt, der beim iPhone und iPad am Seitenanfang/Seitenende auftritt, wenn man versucht weiter zu scrollen als normalerweise möglich. Hier federt die Seite kurz nach, was sie in Safari, Pages und TextEdit macht, unter Firefox bleibt sie wie bisher einfach »stehen«.

Im direkten Vergleich wirkt der FF unter Lion dadurch etwas altbackener (auch durch die ständig sichtbare Scrollleiste).

Jeder wie er möchte. Die Versionsspringerei stört mich allerdings auch. Wenn der »zu kleine Versionsnummer«-Komplex allerdings hilft, Firefox »aktueller« aussehen zu lassen und dadurch User von IE und Chrome gewinnt, soll es mir recht sein. Mir hätte er auch als 4.3 gefallen.

Aronnax:

Nachtrag:

Blargon Blog: Endurance tests demonstrate Firefox’s memory usage improvements

Blargon Blog: Scalability

Gerade der Blogeintrag Scalability lässt aufhorchen, dort wird direkt mit Google Chrome verglichen und wie der sich im Vergleich schlägt.

Fazit am Schluss:

Interessant zu lesen.

LoMacs:
Krypton:

Mozilla Wiki: Priorities for Mac OS X 10.7 feature development:

Insbesondere
Bug #636564 - Include support for new scrollbar features
Bug #673875 - Acceleration/bounce - Reproduce bounce behaviour when reaching top and bottom of documents
Bug #639705 - Integrated full-screen support
Bug #673675 - browser.gesture.swipe.up and browser.gesture.swipe.down don't work in Lion

Meta-Bug #636455 - (lion-compatibility) [10.7] Investigate compatibility with Mac OS X 10.7 "Lion"

Und in den wöchentlich immer Montags stattfindenden Meeting Notes ( und ) kann man dann zwischendurch auch u.a. mal nachlesen, auf welchen Feldern diesbzgl. Fortschritte erreicht worden sind oder wo es noch hakt. Bzw. dort wird dann vermerkt, wenn gewisse stark nachgefragte Bugs/Features dann mit Patch versehen im Trunk (Nightlies) gelandet sind (wie z.B. hier ).

Allgemein: für Planungszwecke und der Vollständigkeit halber hier die Terminierung für die nächsten kommenden Releases:

Mozilla Wiki: RapidRelease/Calendar
Mozilla Wiki: Merge and Release Dates
Mozilla Firefox: Development Specifics (grafische Darstellung des Release-Schemas)

Konstant wird da also regelmäßig alle 6 Wochen ein Release ausgespuckt, die in den Channels (Nightly, Aurora, Beta (RC)) vorliegenden Kandidaten rücken zeitgleich wie die Zähne eines Haifisches jeweils um einen Platz nach vorne bzw. eine Stufe weiter. Berechenbarer für Benutzer, Admins und (Add-On-)Entwickler geht's doch kaum.

Berechenbar ja aber auch mit Nachteilen verbunden.
Während ein Add-On vorher vielleicht ein Jahr ohne Aufwand für den Entwickler lief, muss er jetzt alle paar Wochen testen und überprüfen.

Es macht für die Qualität der Releases auch keinen Unterschied, ob jetzt die Nummer vor dem Dezimalpunkt oder hinter demselben erhöht wird.

Für die Anwender verlieren die Nummern und Versionen schlichtweg ihr »Gesicht«. Früher™ konnte man eine neue Version noch feiern (wie bei FF3 geschehen), die Anwender hatten noch ein ungefähres Bild von einer Version (Netscape 4.7 oder IE 6 anyone?). Man konnte bedenkenlos von 2.2 auf 2.3 upgraden, da man wusste, dass es sich nur um kleinere Änderungen handelt, welche keine große Umstellung oder Kompatibilität gefährdet. Heute weiß man nicht, ob hinter einer neuen Version nur eine schnellere JS Engine steckt, radikale GUI Änderungen vorgenommen oder ganze Workflows aus den Angeln gerissen werden.

Für manche Anwender wird der Browser zu etwas lästigem, da er nicht einfach läuft wie eine Mikrowelle, sondern alle paar Wochen ein Update will, man immer die Plug-Ins prüfen muss, sich auf mögliche Änderungen einstellen darf, etc. Das geht bei Google mit wenigen Plug-Ins und einem Zwangs-Auto-Update vielleicht noch. FF entfernst sich dadurch aber etwas vom »Browser for the rest of us« da die »Pflege« zu Aufwändig zu werden droht.

Auch für Web-Entwickler wird es nicht einfacher, wenn sie auf immer noch mehr Browser testen müssen.

Es hat seine Vor- und Nachteile, ich hoffe mal, dass die ersteren auf lange Sicht überwiegen werden, aber die Zeit ist so freundlich und wird es uns zeigen

Baut er sie mit mit JetPack, benutzt er feststehende APIs und Mozilla muss sich darum kümmern das sie auch weiter funktionieren. Das Argument zählt also nicht mehr wirklich.
Bei Themes wäre es z.B. etwas anderes weil es vergleichbares dort nicht gibt (Personas Kram mal ausgenommen), aber eben nicht (mehr) bei Erweiterungen.
Sowieso ist es doch immer ein großes Argument gegen Firefox gewesen, dass Erweiterungen eventuell bei der nächsten Version nicht mehr funktionieren. Das Argument fällt mit JetPack eben auch weg.

Man kann die Nummern so gar nicht mit den alten Vergleichen. Selbst Firefox 3.6 hatte im Vergleich zur 3.5 ungleich mehr Änderungen als jetzt die 6 zur 5.

Alle sechs Wochen gibt es einfach keine radikalen Schritte. Man bekommt z.B. alle paar Wochen mit, ob sich Firefox in eine für sich gewünschte, oder eben weniger angenehme Richtung bewegt - sonst sicher nichts.

Google z.B. supported selber nur die drei letzten Chrome Versionen. Die älteste unterstützte Version ist dann also nur wenige Monate alt. Klappt auch durch die Autoupdates von Chrome wunderbar. Firefox macht es ja nun ebenso - aus gutem Grund.
Preisfrage: Was mögen Webentwickler wohl lieber. Seiten für super aktuelle Browsern anzupassen und zu testen, oder uralten Schrott zu unterstützen/testen. Was kostest mehr Zeit und Geld?

Für wen? Für Dich als Anwender sind's nur Vorteile. Und für den Entwickler ist die Pflicht halt größer geworden, jederzeit zu wissen und auch zu kontrollieren ob sein Add-On auch noch so läuft wie es laufen soll. Solange keine API-Änderungen stattfinden, ist er weitgehend auf einer einigermaßen ruhigen Seite. Wenn aber API-Änderungen stattfinden und sich ankündigen, dann ist er auf diese Weise viel eher am Ball, bekommt das viel eher mit, weil er gezwungen ist, sich die ganze Zeit diesbzgl. auf dem Laufenden zu halten. Das war bisher nicht ("Fire and forget") der Fall.
Das alles ist dehr im Sinne eines stabileren Browsers, im Sinne der Anwender.

Richtig. Er MUSS sich jetzt um sein Add-On kümmern und regelmäßig testen und prüfen. Bis Firefox 4 gab's da keinen diesbzgl. Druck. Das war "Fire and forget!", "Nach mir die Sintflut." Einmal ein Add-On geschrieben und dann auf die faule Haut gelegt. Während der Browser sich weiterentwickelt hat. Und dementsprechend gab's dann auch schlecht gepflegte Add-Ons, die den Browser instabil gemacht haben, weil sie systembedingt auf alles Zugriff hatten.
Zumal bisherige Nicht-JetPack-Add-Ons nach bisherigem Brauch keinerlei Einschränkungen haben, was sie am Browser verändern dürfen und das nicht. Bisher konnte jedes Add-On uneingeschränkt überall ran an den Browser und ihn verändern. Folge: Add-Ons, die den Browser ausbremsen können oder instabil machen können. Das wird jetzt seit Firefox 4 eingeschränkt und kanalisiert durch eine neue API, Zugang dazu via JetPack SDK.
Und auch bzgl. der Auswahl der Add-Ons wird Firefox restriktiver: ab FF7 werden nur noch Add-Ons zugelassen, die der Nutzer aktiv bestätigt hat. Durch die Hintertüre von einigen Herstellern installierte Add-Ons (z.B. von Microsoft) werden dann auf diese Weise gleich an der Eingangstüre abgefangen und können nur nach ausdrücklichem "Ja" auf eine explizit gestellte und erläuternde Frage vom Benutzer dann installiert werden.

Richtig.

Kann ich in dieser Auslegung so nicht unterschreiben.

"Früher" und in den Zeiten, an die Du da so nostalgisch zurückdenkst, gab's aber auch nur zwei relevante Browser-Hersteller (Netscape und Microsoft) bzw. 3, wenn man Opera noch gnädigerweise hinzuzählen mag. Da drehte sich die Erde insgesamt langsamer, da ging eh alles viel gemählicher und beschaulicher zu. Inzwischen hat sich die Welt aber weitergedreht, und die vielen Konkurrenten, die da hinzugekommen sind und die inzwischen alle ausnahmslos auf einem sehr hohen Niveau spielen, die stacheln sich da gegenseitig an, was Funktionen, Schnelligkeit und Rafinesse angeht. Sprich: das Rad dreht sich inzwischen schneller, die Taktzahl hat sich erhöht, der Druck auf die Browser-Hersteller ist gewachsen, hier regelmäßig Output zu liefern. Selbst an Microsoft geht diese harte Konkurrenzsituation nicht spurlos vorüber. Wenn die da noch mitreden wollen und nicht hintenüber fallen wollen, müssen die sich dem anpassen. Einmal qualitativ. Und auch von der Taktzahl her. Der IE9 war noch gar nicht draußen, da haben die schon angefangen, die ersten Entwickler-Builds des IE10 zu verteilen. Also auch da eine schnellere Taktzahl. Wie bei den anderen auch.

Deswegen haben die Browserr mittlerweile alle Auto-Update-Funktionen. Sowohl sich selber betreffend als auch die Browser-Erweiterungen betreffend. Die erneuern sich schon vielfach während des laufenden Betriebes ohne dass der Anwender da groß was machen muss. Und Add-Ons in Firefox, die via JetPack-SDK geschrieben oder neu geschrieben worden sind, die haben diese Fähigkeit das Auto-Updates gleich mitgeliefert, die erneuern sich selber unter der Haube, ohne dass Du als Anwender da groß was von mitbekommst oder irgendwie intervenieren musst. Gleiches bei Safari und Googles Chrome.

Du als Anwender musst das eigentlich auch nicht wissen. Entwickler und Add-On-Entwickler, die sollen und müssen das wissen. Und die werden durch die neuen Mechanismen besser als zuvor angehalten, hier ein Auge drauf zu haben. Wer ein Add-On schreibt und öffentlich zur Verfügung stellt, der trägt auch sowas wie Verantwortung für sein "Baby". Und genau diese Verantwortung wird durch diese neuen Mechanismen halt stärker eingefordert. "Fire and forget" seitens des Entwicklers ist halt nicht mehr.
Profiteur davon: der Anwender.

Siehe zuvor Gesagtes. Ziel ist es, dass Du als Anwender alles das möglichst eben nicht mehr mitbekommst bzw. Du Dich drum kümmern musst. Weil der Browser und die Add-Ons sich diesbzgl. selber organisieren und aktuell halten (sollen). Automatisch und im Hintergrund und ohne dass Du als Anwender da groß in Beschlag genommen wirst. Und auf dem Weg hin zu diesem Ziel befinden wir uns gerade. Je mehr und je schneller die Add-On-Entwickler ihre Add-Ons in Richtung JetPack, das dem allen unterstützend unter die Arme greift, umgesattelt haben, desto besser. Bei Mozilla gibt es Listen mit den am meisten nachgefragten Add-Ons und Add-Ons, die am meisten Performance verbrauchen. Das sind die Kandidaten, die am ehesten und am schnellsten auf JetPack umstellen sollen, es schon haben bzw. mit Mozilla hier in engem Kontakt stehen.

Kappes. Die sollen auf Features testen und nicht auf irgendwelche Browser-Strings und Browser-Versionsnummern. Das war schon früher falsch und ist es heute erst recht. Entweder ein Browser kann eine bestimmte Sache, oder er kann sie nicht. Völlig egal, welcher Hersteller und welche Versionsnummer. Wer auf Features hin testet, dem können Hersteller und Versionsnummern völlig egal sein. Und was die vorausschauende Planbarkeit von Features angeht, so ist wohl gerade Firefox unter all den Browsern die es da heute gibt, wohl derjenige welche, bei dem man noch am ehesten weiß und vorab erfahren kann, was er an kommenden Features haben wird, so gut und so offen, wie das alles regelmäßig dokumentiert und auch kommuniziert wird. Nur muss man dann halt auch mal öfters in diese Dokus reinschauen als Entwickler. Das wird leider von zu vielen viel zu selten gemacht. Auch ganz allgemein bezüglich anderer Themen und auf anderen Feldern in der Software-Entwicklung. Da liegt die eigentliche Krux -- viele Entwickler sind schlichtweg nicht ausreichend informiert bzw. halten sich nicht ausreichend auf dem Laufenden und glauben im Zweifel dann lieber irgendwelchen fehl- oder uninformierten Blogs, anstatt mal selber einen Blick in die Dokus und Primärquellen zu werfen. Das ist leider ein eher allgemeines Problem, da gäbe es noch ganz andere Beispiele zu nennen. Leider.

Ich kann an der geänderten Versionierung keine Nachteile erkennen, die von einigen Kritikern genannten Nachteile sind für mich keine und sind für mein Dafürhalten allein dem Gewöhnungseffekt geschuldet. Sie ist für das Funktionieren und die Pflege des Produktes im Grunde völlig unerheblich. Es gibt da draußen zahlreiche durchaus weit verbreitete Software, die ist seit Jahren stabil und zuverlässig im Einsatz und hat noch nicht mal eine echte Versionsnummer -- da ist teilweise die Versionsnummer das Datum ihrer letzten Veränderung. Und? Tut das dem Einsatz und der Qualität dieser Software irgendeinen Abbruch? Nö. Sowas juckt eigentlich keinen, der diese Software einsetzt.

Nein muss er nicht. Ist ja gerade der Sinn von JetPack und den feststehenden APIs. Schreiben und dann auf die faule Haut legen - genauso soll es sein. Vorher ging das eben (leider) nicht bei Firefox Erweiterungen bzw. der Druck zu testen und warten war vorher auch ungleich höher.

Für komplexere Projekte gibt es anderseits auch noch das das alte Modell. Ein Grund bzw. der Grund, warum Firefox immer noch die besseren Erweiterungen hat. Safari und Chrome sind schlicht wesentlich eingeschränkter - vergleichbar zu JetPack.

Eine klassische »wenn« »dann« Argumentation, die aber nicht zwangsweise jedem hilft.

Ich beispielsweise (wobei ich sicher nicht den Normalo repräsentiere) habe 1Password und DevonThink Pro bei mir installiert, welche beide ein Add-On in den Browser stecken. Diese Add-Ons wurden seither bei jedem Browser-Update erneuert, was im Umkehrschluss für mich bedeutet, das ich alle 6 Wochen nach Updates für die beiden Programme suchen muss, warten darf, bis diese da sind, das Update durchziehen darf und dann erst das FF-Auto-Update zum Zug kommen lassen darf.

Das hat die Tendenz zu nerven.

Auch hier wieder die schöne Theorie. Im aktuellen Browser-Report von ars-technica sieht man beispielsweise sehr schön, wie ein immer größerer »Rattenschwanz« von alten Versionen in der installierten Basis entsteht. In sofern betrifft es die Web-Entweickler doch, da der Aufwand zu prüfen, ob eine neue Funktion jetzt eingesetzt werden kann oder nicht, noch immer prozentual von den genutzten Browsern abhängt.

Bei jedem Versionssprung gibt es einige User, die diesen nicht mit machen, so dass deren Anzahl bei steigender Releasezahl zu wachsen droht. Auto-Updates und Support alter Versionen hin oder her.

Wie schon oben erwähnt, bin ich nicht generell dagegen und ich bin auch nicht der, welcher gerne auf alten Versionen rumsitzt. Trotzdem sollte man die Nachteile dieses Systems nicht in Wunderland-Geschenkpapier einwickeln und alles schön reden.

Nein, siehe im vorherigen Post als Antwort auf Aronnax


Nun, ich als Anwender würde aber gerne wissen, ob sich die GUI in einem Release komplett ändert, ob Funktionen gestrichen oder so umgebaut wurden, dass sie meinen Workflow beeinträchtigen – bevor ich das Update einfach abnicke.
Problem jetzt: ich muss mich vorab bei jeder Version informieren, während das früher nur einmal im Jahr notwendig war.
Dabei sehe ich wieder nicht unbedingt mich selbst als »Opfer«, da ich in der Regel mit so ziemlich allem klar komme. Allerdings betreue ich auch die Rechner von einigen Senioren und Menschen, die den Rechner eher mal beiläufig verwenden. Die sind von solchen Änderungen meistens nicht sehr »amused«.


Nochmal bezugnehmend auf meinen vorigen Eintrag, muss ich auch hier nochmal den Browser-Report von ars-technica einwerfen . Selbst wenn ich auf Features teste (womit du natürlich recht hast) gibt es trotzdem das Problem, dass ich mich mit einer zunehmenden Basis an Alt-Browsern herumschlagen darf und für deren nicht vorhandene oder fehlerhaft implementierte Features einen Workaround implementieren muss.

Vermutlich immer noch besser als das was zu Zeiten der IE6 Dominanz zu schultern war. Dennoch könnte sich durch die »Update-Verweigrer« hier ein neues Problemfeld anbahnen. Wir werden sehen.

Wieso Theorie? Bei ars-technica sieht man doch wunderbar, wie es bei Chrome funktioniert (alle alten Chrome Versionen sehr, sehr deutlich unter einem Prozent bzw. zählen eben nicht mehr) und bei Firefox ab der 4er sieht es nun nach einer ähnlichen Entwicklung aus. Ist doch eine mehr als eindeutige Verbesserung, oder etwa nicht?
Was erwartest du denn? Das diese Änderungen über Nacht alle Probleme lösen Vergleichbares kann man zu den Erweiterungen sagen.

Einerseits, wie bereits erwähnt kann Mozilla gar nicht alle sechs Wochen die GUI komplett ändern. Umgebaut wird sie ansonsten definitiv immer mal wieder hier und dort.
Wenn zum Beispiel Firmen oder Senioren eventuell damit nicht klar kommen. Ja dann, die Sache ist doch ganz einfach: Opera, Chrome und Firefox haben einen schnellen Versionswechsel. Der IE und Safari nicht, werden es auch sicher nicht bekommen. Da wählt man sich eben den passenden Browser - so einfach ist das

Für TenFourFox, dem PPC-Pendant zu Firefox ab Version 4.0, gibt es den Vollbildmodus schon seit Version 5. Über Gesten kann ich mangelst Hardware nichts sagen. Das Scrollverhalten ist hier (iMac G5) keinesfalls schlechter als mit Safari. Leider werden ab Version 6.0 default browserübergreifenden PPC-Plugins, sowie einige Add-ons (z.B. Flashblocker) nicht mehr unterstützt. Das führt u.a. dazu, dass man zwar weiterhin eingebettete Flashclips im alten UI-Design starten kann, aber YouTube nach dem neuesten Flashplayer-Plugin verlangt, welches es leider nicht mehr für PPC gibt.
Allerdings kann man die meisten Einschränkungen via "about:config" auf eigenes Risiko wieder freischalten. So funktioniert nun YouTube mittelst Flashblocker wieder einwandfrei.
Wenn ich TenFourFox auch noch dazu bringen könnte .pdf Dateien im Browser anzuzeigen, bzw. Audiofiles auf Seiten wie dic.cc oder Google Translate abzuspielen, wäre - wenigstens für’s Erste - alles in Butter.
Das hier mehrfach angesprochene Problem mit inkombatiblen Add-ons existiert schon und ist teilweise ziemlich nervig. Beispielsweise fehlen immer noch aktuelle iGetter-, sowie Tor-Add-ons. So bleibt halt Firefox 3.6 weiterhin auf meiner Platte.

Edit: Audio-Problem gelöst. KEIN www. vor die Einträge in der Whitelist von Flashblock und alles ist gut.

3 Möglichkeiten: Entweder via

firefox-mac-pdf
PDF plugin for Firefox on Mac OS X

Nachteil: wird vom ursprüngl. Entwickler leider nicht mehr weiterentwickelt, gibt's leider nicht als 64bit-Version. Funktioniert also nur dann, wenn man den Browser im 32bit-Modus laufen lässt. Ist aber ein i386/PPC Universal Binary, ließe sich also mit einem PPC Firefox betreiben. Nutzt MacOSX' natives PDF-Framework PDFKit, funktioniert also im Grunde genauso wie Safaris eingebauter PDF Viewer.

Von firefox-mac-pdf gibt es für die Browser ab FF 4 keine offizielle Version (wie gesagt, der ursprüngl. Entwickler hat die Entwicklung eingestellt, und die Community ist bislang nicht fähig, hier einen fähigen Nachfolger bereitzustellen bzw. es findet sich niemand). Es gibt jedoch eine inoffizielle Version des Add-Ons, welches befähigt worden ist, unter FF4, FF5 und höher zu laufen, vorausgesetzt, Firefox läuft im 32bit-Modus (was er standardmäßig nicht tut, sondern standardmäßig im 64bit-Modus läuft, man muss ihn dazu per Finder Rechtsklick Informationen erst dazu zwingen). Diese inoffizielle Add-On-Version trägt die Versionsnummer 1.2.0 und ist in den Tiefen diverser Issue-Diskussionsfäden auf der Projektseite verlinkt. Zum Beispiel in Issue 182, Kommentar #28 und #36 . Oder auch in Kommentar #11 von Issue #202 .

Es lässt sich nur dann installieren und läuft nur, wenn Firefox im 32bit-Modus läuft. Wird FF danach wieder in den 64bit-Modus (Standard-Modus) geschaltet und betrieben, so bleibt zum Glück das Add-On erhalten, wird von Firefox also nicht rausgeschmissen, ist aber deaktiviert und läuft nicht, ist dann also nutzlos und nicht zu gebrauchen.

2. Möglichkeit:

Schubert|IT: PDF Browser Plugin

Nachteil PDF Plugin Schubert|IT: das setzt sich in /Library/Internet Plug-Ins und fungiert für alle Browser, also auch Safari. Setzt sich damit vor die in den Browsern evtl. eingebauten nativen PDF-Viewer.

3. Möglichkeit:

Auf Mozillas native PDF-Lösung, PDF.js , warten. Mir hat der Projektleiter Andreas Gal unlängst auf meine Nachfrage mitgeteilt, dass eine erste lauffähige Version für diesen August geplant ist. Mal abwarten, ob und wann und wie die dann ist.

Ich habe oben bereits Mozillas Add-On-Compatibility Reporter angesprochen, den man sich installieren kann/sollte.
Der ermöglicht es, vom Browser automatisch als inkompatibel markierte und deaktivierte Add-Ons, wieder zu aktivieren und das Signal per Meldung an Mozilla und den betreffenden Entwickler zu senden: "Funktioniert trotzdem (noch)" oder "Funktioniert aus den und den Gründen leider nicht".

Dieses Compatibility Reporter Add-On installieren, evtl. deaktivierte Add-Ons trotz Warnung wieder aktivieren, und Du bist fein raus. Zu gegebener Zeit erneuern die sich dann automatisch und ohne Dein Zutun im Hintergrund, sollte eine neuere Version bereitstehen.

Im Fall von iGetter kann ich keine Aussage treffen, weiß ich nicht. Bzgl. Tor-Add-On habe ich die Vermutung, dass es da sehr wohl was gibt, es Dir nur bisher nicht über den Weg gelaufen ist. Vielleicht nochmal auf Suche gehen. Bist ja nicht der Einzige, der das gerne benutzen will.

Aussage eines Add-On-Entwicklers mir gegenüber:

Außerdem: nicht jedes Add-On lässt sich auf einfache Weise in JetPack überführen. Bisher sind viele Add-Ons mit dem jahrelang notwendigen und seit FF4 64bit fähig gemachten XulRunner SDK gebaut. Sie können nicht so ohne Weiteres in JetPack nachgebaut und in ein rein JavaScript-basiertes Add-On überführt werden. Manche Add-Ons müssen binär gebaut werden, kommen um XulRunenr nicht drumherum bzw. tragen irgendwelche Binaries in sich (welche eben nur via XulRunner und nicht via JetPack gebaut und eingebunden werden können). Und gerade diese sind es, die bzgl. Versionsnummern mittlerweile passgenau zum Browser bzw. zur Browser-API gerichtet sein müssen, Mozilla verlangt das mittlerweile so. Und genau hier ist dann die Aufmerksamkeit und die Wachsamkeit des betreffenden Add-On-Entwicklers gefragt (siehe auch obiges Zitat). Wildcards (wie z.B. "*") bzw. vorgreifende maxVersion-Strings sind also so ohne Weiteres nicht mehr von Mozilla geduldet, wer sowas versucht, dessen Add-On wird gar nicht erst von Mozilla für addons.mozilla.org zugelassen und abgewiesen. Punktgenaue Versions-Landung ist somit erforderlich. Zumindest für die Add-Ons, die mit XulRunner erstellt worden sind bzw. werden und einen Binär-Anteil in sich tragen.

Ein großer Anteil existierender Add-Ons hat jedoch keinen Binär-Anteil in sich, sondern besteht ohnehin nur aus JavaScript, XUL/XML-Dateien und Bildern, kann also sehr leicht in ein JetPack-Add-On überführt werden. Und da kann das dann auch mit den Versionsnummern lockerer gehandhabt werden bzw. da spielt die Browser-Version bzw. die Browser- und Add-On-API dann in der Tat keine tragende Rolle.

hier die mtn Seite ruckelt mit ff schon sehr stark. das ist kein Blödsinn wie manche Eierköppe hier schreiben, sondern real. oder sitzt du vor meinem recher @ aronnax? das wüsste ich....

man man man, was manche sich immer so denken. wenn es bei mir und lomacs ruckelt, dann ruckelt es bei mir und lomac mit dem firefox!

sierkb, keine besonderen plus installiert, nur das webdev und firebug.

Du bezieht dich doch auf auf "im Vergleich zu Safari ruckelndes Scrolling". Ist allgemein eben Blödsinn und weiß der Teufel, was einige Eierköppe so anstellen, damit es auf ihren Kisten so ist. Aber was soll man einigen Eierköppen auch anderes erwarten

richtig, was soll man von denen erwarten, du sagst es. ich erwarte auch kaum, dass manche wissen, was rückenfrei ist!

Wozu Firefox? Jedes Mal so ein Hype nur weil die ein neues Update herausbringen. Ich brauche nur Safari und mehr nicht.

seh ich auch so, aber der firebug für firefox ist ungeschlagen. das tool brauche ich, wie nix anderes. klar hat der safari eine ähnliche funktion, aber so komfortabel wie der firebug ist sie nicht. jedenfalls nicht für mich.

"Nur" ist gut. Ausgerechnet Firebug nennst Du mir da...
Das Firebug Add-On ist zufälligerweise genau jenes welches, das den Browser am MEISTEN ausbremst. Weil es so sehr tief ins DOM jedes geladenen Webinhaltes eingreift. Deshalb gibt's bei Mozilla auch das Bestreben, Firebug funktional ein wenig dahingehend zu entlasten oder überflüssig zu machen, dass man ein paar Features, die oft benötigt werden, davon gleich in den Browser integriert, damit dann sozusagen ein Firebug/WebDev Light sozusagen anbietet. Und nur wer den vollen Umfang benötigt, der greift dann auf das voll umfängliche Firebug Add-On zurück.

Schau mal selber, was Mozilla uns da präsentiert:
Mozilla: Slow Performing Add-ons :

Platz #1 Firebug (bremst den Browser zu 68 Prozent aus)

Die Liste listet zwar nur die ersten 10 an Add-Ons auf, in seinen ersten Tagen hat man sich bei Mozilla noch die Mühe gemacht und hat ein paar mehr Plätze angezeigt. Auch die Developer-Toolbar war auf dieser Liste auf einem der oberen Ränge und nicht ganz am Schluss genannt. Sie kann man nur leichter bei Bedarf von der Toolbar aus an- und abschalten, ohne den Browser neustarten zu müssen. Bei mir ist sie standardmäßig abgeschaltet und wird per Klick nur gerufen, wenn ich sie benötige.

Deshalb nicht nur von den Mozilla-Leuten der Tipp: solche Add-Ons nur dann aktivieren, wenn man sie unbedingt braucht. Werden sie nicht benötigt, dann deaktivieren. Ich richte mich danach, handhabe das genau so und fahre ziemlich gut damit, ich habe null Performance-Probleme. Bei mir sind nur ganz wenige Add-Ons von denen, die ich installiert habe, permanent und für den day-by-day-usecase aktiviert. Der Rest schlummert bei mir deaktiviert und wird vereinzelt nur hinzugerufen, wenn ich dessen Funktionalität in dem Moment dringend brauche, danach geht's wieder zurück in die zweite Reihe (deaktiviert).

Oder auch verschiedene Firefox-Profile einrichten, zwischen denen man dann vor dem Start des Firefox wählen kann: z.B. ein Developer-Profil, bei dem solche Add-Ons alle standardmäßig aktiviert sind und ein Profil für den Alltag, bei dem solche Add-Ons wie das Firebug Add-On standardmäßig deaktiviert sind.

ackerratte:

The Register: Mozilla puts squeeze on slow Firefox add-ons
Firebug tops slow startup list

The Register: AdBlock Plus man disputes Mozilla add-on tests
Slow Firefox startup list pared

ghacks.net: Mozilla: Each Firefox Add-on Adds 10% To Firefox Startup On Average

Mozilla Add-ons Blog: Improving Add-on Performance

Mozilla Add-Ons Blog: Update on Add-on Performance Testing

Mozilla MDN Docs: Performance best practices in extensions

Die Liste ist ja nicht wirklich ernst zu nehmen, da sie lediglich die Plugins auflistet, welche den »Start« von Firefox verzögern. Ob das Programm 3 Sekunden länger startet ist mir so ziemlich wurst, da es danach eh tagelang ohne Neustart vor sich hin läuft.

In sofern vermittelt die Liste leicht ein falsches Bild. Es ist schon ein Unterschied, ob lediglich der Start länger dauert, oder ob es das Surfen/Scrollen ansich beeinträchtigt.

Die Idee mit dem manuellen aktivieren und deaktivieren von Plug-Ins ist zwar gut, finde ich für meine Zwecke viel zu Aufwendig, von der Verwaltung verschiedener Profile mal ganz abesehen.

ackerratte Es ist jedoch manchmal ganz hilfreich, Firefox testhalber mit einem neuen, leeren Profil zu starten, um zu sehen, ob ein eventueller Fehler aus dem eigenen und möglicherweise defekten Profil kommt. Bei einem Update in der Vergangenheit (ich glaub’ von 2 auf 3) musste ich wegen grober Performance-Probleme auch das Profil neu anlegen. Danach lief der Fux wieder rund.

Weil's thematisch grad' passt:

heise: Die Woche: Firefox und die Updates
Die neue Update-Strategie bei Firefox bringt Verbesserungen schneller zu den Anwendern. Das ist gewöhnungsbedürftig und benötigt vielleicht noch Feinschliff, ist aber in Zeiten schneller Internet-Verbindungen der richtige Weg.

Das solltest Du aber tun.

Liest Du immer so oberflächlich und ungenau? Nicht immer nur die Überschriften konsummieren, sondern auch mal den ganzen Text der Dir gegebener Quellen.

Was steht z.B. im Einleitungstext von

Mozilla: Slow Performing Add-ons

Da steht:

Es geht also nicht allein um die Startup-Performance. Sondern um die Gesamt-Performance des Zusammenspiels zwischen Browser und Add-On!

Gerade bei solchen Add-Ons wie Firebug, der Web Developer-Toolbar und auch solchen Add-Ons wie Ad-Blockern. Warum gerade bei denen? Weil die am meisten in das Document Object Model (DOM) der in den Browser geladenen Seiten eingreifen und diese paresen und filtern, jedes einzelne Element der Seiteninhalte da durch deren Finger geht. Und das kostet eben Zeit. Erst recht kostet das Zeit, weil das DOM seriell aufgebaut ist und von oben nach unten abgearneitet wird. Parallelverabeitung kennt das DOM nicht. Und JavaScript wird i.d.R. auch von oben nach unten und nicht parallel abgearbeitet. Man kann dessen Abarbeitung verzögern und auf einen späteren Zeitpunkt verlegen bzw. erst dann abarbeiten lassen, wenn die Seite vollsträndig geladen ist mittels des defer-Attributes. Aber auch dann wird der Code von oben nach unten abgearbeitet.

Und Tools wie Firebug und die Web Developer Toolbar oder auch eben Adblocker, die sind mächtig. Die können jedes einzelne Bit im Content-Fenster des Browsers umdrehen und beeinflussen bzw. diese Add-Ons klinken sich in den Datenstrom. Deshalb ist bei Ad-Blockern z.B. angeraten, sich auf möglichst wenige Filterlisten zu beschränken, die man abonniert. Um den Parsing-Aufwand dadurch auf ein Minimum beschränkt zu halten und dem Browser nicht noch aufhalst, die Bits der Webinhalte im Browser nicht noch durch eine große Anzahl an Filterlisten durchzujagen, sondern durch vielleicht eine oder zwei.

Dann musst Du mit den damit einhergehenden Performance-Einbußen eben leben. So einfach ist da meine Antwort auf sowas. Und zwar grundsätzlich betrachtet, nicht nur Firefox betreffend. Es ist eine grundsätzliche Sache. Und Gewöhnungssache. Ich jedenfalls brauche nicht ständig einen aktivierten Firebug und eine aktivierte Developer-Toolbar. Und solange ich die nicht brauche, sind und bleiben die deaktiviert. Wenn ich sie brauche, hole ich sie mir mit einem Klick aus der Versenkung hervor. Safari und andere Browser haben ihre Entwickler-Menüs auch standardmäßig deaktiviert, und man aktiviert sie erst dann, wenn man sie benötigt. Warum wohl?

Mein mod_tidy-Apache2-Modul, das sich sehr ähnlich den oben genannten Browser-Add-Ons in den Ausgabestrom des Webservers einklinkt, das verlangsamt und verzögert aus gleichen Gründen ebenfalls die Ausgabe im Browser um ein paar Mikro- und Milisekunden, weil jedes Bit des Datenstromes erstmal durch den Filter dieses Modules läuft und dann erst den Browser erreicht. Das wird auch nur dann aktiviert und benutzt, wenn es unbedingt erforderlich ist und ist nur für den lokalen Entwickler-Einsatz gedacht und nicht für Produktions-Webserver, die am öffentlichen WWW hängen und ausbremsende Faktoren nicht gebrauchen können. Aus gleichen Gründen.