Mozilla stelt Firefox 3.1 opnieuw uit

Mozilla heeft de derde bètaversie van Firefox 3.1 uitgesteld. De belangrijkste reden voor de vertraging is de nog niet helemaal correct werkende JavaScript-engine. De kans bestaat dat Firefox 3.1 daarom niet in het eerste kwartaal verschijnt.

Uit het verslag van de Firefox 3.1-voortgangsbijeenkomst die op 28 januari werd gehouden, valt op te maken dat er nog achttien bugs opgelost moeten worden voordat de derde bèta van Firefox 3.1 kan worden uitgebracht. Een klein deel van deze bugs is eenvoudig op te lossen, maar bij het leeuwendeel gaat het om 'lastige problemen die om een gecompliceerde oplossing vragen', zo staat in het verslag te lezen.

Vrijwel alle moeilijk oplosbare bugs zijn te herleiden tot TraceMonkey, de nieuwe JavaScript-engine die de uitvoering van JavaScript aanzienlijk moet versnellen. JavaScript-code wordt door TraceMonkey in vergelijking met Firefox 3.0 en Firefox 2.x respectievelijk twee en negen maal zo snel uitgevoerd. In samenspraak met de verantwoordelijke ontwikkelaars zal een nieuw releaseschema worden opgesteld. Er wordt niet overwogen om TraceMonkey weg te laten om Firefox 3.1 alsnog volgens schema uit te kunnen brengen.

Het is toch al niet de eerste keer dat de derde bèta van Firefox 3.1 wordt uitgesteld. Twee weken geleden nog liet Mozilla weten dat de bèta op 2 februari zou verschijnen, een week later dan oorspronkelijk de bedoeling was. Tot eind november 2008 was er zelfs nog helemaal geen sprake van een derde bèta, maar die werd noodzakelijk geacht om de nieuwe JavaScript-engine beter en grondiger te kunnen testen. De tweede bèta van Firefox 3.1 werd begin december 2008 gepubliceerd.

Reacties (77)

[jbdeiman]

Werken je skins ook in de huidige 3.0? Dan hoef je de skins niet aan te passen, tenminste daar is voor zover nog geen melding over gemaakt. Er veranderd e.e.a. aan de achterkant (stukje sneller) maar voor de rest hoef je je geen zorgen te maken over je skins.

Versie 3.0 is namelijk al een tijdje uit en stabiel (ik neem aan dat je de recordpoging nog wel kan herinneren van Mozilla, voor het aantal downloads? Dat is versie 3.0)

Het gaat nu om versie 3.1.

Dat JavaScript sneller wordt vind ik wel prettig, je krijgt steeds meer websites met allerlei JS code, die de boel allemaal verfraaien (vooral met frameworks en Lightbox en dergelijke). Al moet ik zeggen dat de huidege javascript engine me niet tegenvalt hoor.
Wat wel tegenvalt is het geheugengebruik, iemand op de hoogte of dat aan is of wordt gepast? Ik vind het een beetje raar dat als je een aantal tabs open hebt staan met websites van ong. 100kb dat (het gemiddelde) per website aan geheugengebruik in Firefox ver boven de 10mb per pagina ligt.

[Reactie gewijzigd door jbdeiman op 24 juli 2024 16:44]

[Towap]

Dat komt deels ook omdat FF per tab, default een aantal eerder bezochte pagina's in cache houdt (10 per tab?). Je kan dus minder tabs gebruiken of de geschiedenis per tab verkleinen.
Als ik zo snel kijk, kan je dit aanpassen door in about:config de waarde browser.sessionstore.max_tabs_undo aan te passen.

Een andere truuk om het geheugen kleiner te houden vind je door te googlen: je kan namelijk instellen dat ie geminimaliseerd praktisch volledig naar je virtueel geheugen overgaat, die key ken ik nu niet van buiten en zit op het werk.

[jbdeiman]

Voor zover wist ik dat nog wel,maar toch bedankt voor de uitleg en moeite die je genomen hebt.

Maar waar ik op doelde wat mij het meest opvalt is dat het geheugengebruik niet (of nauwelijks) afneemt als ik één of meerdere tabs sluit. Dat vond ik één van de voordelen van Googles Chrome, als je daar een tab sluit omdat je browser wel heel zwaar werd (alles bij elkaar) dan werd het geheugengebruik ook echt minder.

[Reactie gewijzigd door jbdeiman op 24 juli 2024 16:44]

[wankel]

Maar waar ik op doelde wat mij het meest opvalt is dat het geheugengebruik niet (of nauwelijks) afneemt als ik één of meerdere tabs sluit.

Ik denk dat hij daar juist op doelt: "undo close tab" is standaard aanwezig meen ik, en met tab mix plus kan je er zoveel aan toevoegen als je wilt, inclusief history voor die gesloten tabs.

Ik heb zelf niet geprobeerd of het geheugengebruik afneemt als ik die waarde lager zet, en heb vaker gesloten tabs weer nodig dan meer geheugen (maar dat is natuurlijk geen excuus om maar meer en meer geheugen te blijven claimen).

[Reactie gewijzigd door wankel op 24 juli 2024 16:44]

[GoBieN-Be]

Hij is tegen geskinde applicaties, hij is voor desktop integratie, dus het volgen van de desktop skin in alle programmatuur !

[Wim-Bart]

Kan iemand mij uitleggen wat het voor zin heeft dat een Javascript engine 2 keer zo snel is t.o.v. de originele? Computers zijn tegenwoordig zo snel dat je dat toch niet merkt, of zijn er mensen die echt het verschil kunnen zien dat iets in 0,1 ms wordt uitgevoerd of 0,05 ms or zelfs in 0,01 ms.

Daarnaast vraag ik mij af wat voor slechte producten de voorgangers waren wanneer deze engine zo ver geoptimaliseerd kan dan worden. Want waarom heeft men dat niet gelijk gedaan. Zitten de programeurs soms op een cursus programmeren en zijn ze nu net pas in het klasje perfomance aangekomen?

[Maurits van Baerle]

Het gaat niet om minieme verschillen tussen browsers en browserversies, het kan makkelijk om 40x zo snel gaan.

Bij dat soort verschillen gaat het er niet meer om of het voor de gebruiker prettig is dat iets sneller gaat, het gaat er om dat bepaalde toepassingen onmogelijk zijn als de browser te langzaam is. Niet voor niets zijn er steeds meer bedrijven die IE6 gebruikers beginnen te weren (Google is een mooi voorbeeld), een hoop webapplicaties zouden anders ernstig gehinderd worden in hun ontwikkeling omdat IE6 zo extreem traag is.

Voor een simpele site maakt het niet uit. Als je praat over complete online Office-suites of bijvoorbeeld Zimbra dan is het verschil gigantisch en vaak het verschil tussen wel of niet bruikbaar.

[Verwijderd]

bedrogen (...) "slechte" versie

Dat zijn nogal uitspraken.

Kijkend naar andere, officieel uitgebrachte, browsers op het moment Opera 9.63, Safari 3.2, IE7 dan is daar de Javascript performance op ongeveer gelijk aan Fx 3. Alleen het pas uitgebrachte Chrome heeft een snellere Javascript engine. Dus dan zullen alle dev-teams bij die browser bouwers wel prutsers zijn volgens jouw redenering.

Tuurlijk had Fx 3 de Javascript engine kunnen hebben die Fx 3.1 nou heeft (Tracemonkey), echter dan had iedereen nou nog met Fx 2 gewerkt (die nog een mindere Javascript performance had). Het zijn gewoon nieuwe(re) technieken die worden toegepast binnen de browsers die op dat moment nog niet beschikbaar waren. Sowieso, ik durf nou met droge ogen te beweren dat Firefox 3.2/4/whatever nog sneller zal worden dan Firefox 3.1. Dat heeft niets te maken met slechte programmeercodes, maar met evolutie.

FYI: Fx 3.1 maakt gebruik van een JIT (dus Javascript wordt gecompiled voordat het wordt uitgevoerd), Fx 3 maakt nog gebruik van de 'oude' bytecode interpreter waardoor er elke keer een vertaalslag moet worden gemaakt.

[Maurits van Baerle]

Wat een flauwekul. Er is een totaal nieuwe technologie gebruikt. Het gaat niet om kleine optimalisaties in bestaande code maar om het run-time compileren van JavaScript code. Iets wat twee jaar geleden waarschijnlijk ondenkbaar was.

Zo kun je ook zeggen dat een gisteren gelanceerde 2TB harde schijf troep is omdat er volgend jaar een 3TB versie uitkomt. Die natuurlijk ook troep is want, dankzij voortschrijdende technologie, komt er een jaar daarna een 4TB schijf uit.

[vor0nwe]

Nou Wim-Bart, maak je borst maar nat: dan word je zowel met FF 3.1 als met Opera 10, IE 8, en Chrome 3 bedrogen: een paar jaar later brengen ze allemaal weer een snellere en betere versie uit!

Om zoiets in één keer goed te doen, wat jij suggereert, ben je jaren aan het ontwikkelen en testen. Breng je het vervolgens eindelijk uit, is het volledig achterhaald.

Enne, sinds wanneer zijn programmeurs booleans? Ter vergelijking: rij jij je auto dagelijks in de prak, of win je elk weekend een F1 GP? Geen tussenvorm mogelijk? Ga toch fietsen, man!
Iedereen maakt voortdurend beslissingen; soms goede, soms verkeerde; en soms beslissingen die op dat moment goed lijken, maar achteraf toch verkeerd blijken. Programmeurs zijn net mensen wat dat betreft...

[Mike-RaWare]

Daarnaast vraag ik mij af wat voor slechte producten de voorgangers waren wanneer deze engine zo ver geoptimaliseerd kan dan worden. Want waarom heeft men dat niet gelijk gedaan. Zitten de programeurs soms op een cursus programmeren en zijn ze nu net pas in het klasje perfomance aangekomen?

Tracing gaat niet om optimale code, maar om een totaal nieuwe manier om JavaScript te interpreteren. En aan dit document te zien is het een heel lastig karwei om de tracing-techniek te implementeren.

[Verwijderd]

Je merkt het verschil niet tussen 1 ms en 5 ms. Dat is zonder meer waar. Echter, internet begint steeds meer een applicatieplatform te worden in plaats van alleen een platform waar alleen HTML wordt getoond. Deze (toekomstige) applicaties zijn zeer complexe programma's geschreven in Javascript. Hier heeft het wel degelijk nut om deze zo snel als mogelijk te maken.

Daarnaast vraag ik mij af wat voor slechte producten de voorgangers waren wanneer deze engine zo ver geoptimaliseerd kan dan worden.

De vraag/behoefte was er niet naar en bovendien was de technologie er niet voor...

[Reactie gewijzigd door Verwijderd op 24 juli 2024 16:44]

[Verwijderd]

Waar komt die haat tegen programmeurs vandaan Wim-Bart? Nooit afgevraagd of het zaakje wellicht ietsje genuanceerder zou kunnen zijn?

Javascript was tot nu toe een simpele interpreter taal. Dergelijk talen zijn inherent langzamer dan compiler talen, maar hebben ook weer specifieke voordelen t.o.v. compiler talen. O.a. bijvoorbeeld dat je gewoon een paar regels code in een webpagina kunt stoppen, die dan uitgevoerd worden. Bij een normale compiler taal kan dat niet... dan moet je een executable meesturen.

Voor de zaken die tot nu toe in javascript gedaan werken was het dus volkomen logisch en terecht dat men een interpreter taal gebruikte. En voor zwaardere web toepassingen gebruik je dan een compiler taal, zoals Java, en zet dat dan in een applet. Andere opties zijn dingen als ActiveX e.d...

Probleem is dat sommige ontwikkelaars, (o.a. Google) steeds meer met javascript wil doen, maar niet de overstap naar JAVA willen maken. En dan krijg je dus een probleem dat je een interpreter taal zit te gebruiken voor een toepassing waar het eigenlijk niet geschikt voor is.

Daar zijn wel oplossingen voor te bedenken, in de vorm van 'Just-in-time' compilers e.d. Je gaat dan een soort van hybride vorm van interpreter-compiler maken. En dat is dus wat Google in Chrome gedaan heeft, en wat nu ook in FF3.1 komt.

De reden dat Chrome dat heeft, is uiteraard dat Google bezig is grotere (Office) applicaties naar de webbrowser te brengen, maar die niet als een opzichzelf staande JAVA applicatie wil hebben. Daarom dat Google een browser nodig had die sneller javascript kon uitvoeren.

Hoewel een JIT compiler inderdaad Javascript flink kan versnellen, is het niet perse de beste of meest logische oplossing voor het probleem. De toekomst zal het leren...

[Verwijderd]

Ik houd het liever op voortschrijdend inzicht...

[vor0nwe]

...als programmeur met een hart doe je altijd je best om optimale code te schrijven voor gebruiksgemak en onderhoudbaarheid.

...als programmeur met een baas doe je je beste om optimale code te schrijven binnen de tijd en het budget.

En zowel programmeurs met een hart als programmeurs met een baas (of zelfs met beide) maken fouten, leren van hun fouten, etc...

[MSalters]

Javascript is traag. Het verschil is niet 0.1 ms of 0,01 ms, maar 1 s of 0.1 s als je een beetje complex iets wil doen. Neem bijvoorbeeld client-side image generation, als je duizenden pixels wil tekenen.

[Verwijderd]

Computers zijn tegenwoordig zo snel dat je dat toch niet merkt, of zijn er mensen die echt het verschil kunnen zien dat iets in 0,1 ms wordt uitgevoerd of 0,05 ms or zelfs in 0,01 ms.

Een factor 10 in executiesnelheid kun je in veel gevallen merken, vooral bij zichzelf herhalende rekenkundige routines. Maar bij iets wat maar een keer gebeurt merk je het niet.

[3raser]

Houd dit in dat met TraceMonkey Firefox in de buurt komt van de Chrome javascript snelheid?

[user109731]

Ja, die zitten nu aardig in de buurt van elkaar. Chrome is nu vaak sneller, maar TraceMonkey is nog niet helemaal compleet: hoe meer functies en gevallen je "tracet", hoe sneller de code is. Als de code aanroepen bevat naar functies die nog niet getraced worden, dan valt TM terug op de interpreter en dat maakt het direct langzamer. Recursieve aanroepen worden ook nog niet ge-traced, daar kan nog veel gewonnen worden

Tracing kan denk ik efficientere code genereren (het is simpel gezegd een vorm van loop en function inlining, waardoor je beter kunt optimaliseren), maar heeft mogelijk wel meer overhead. De JS-engine van Chrome compileert JS direct naar ASM, zonder bytecode of interpreter ertussen. Dat zorgt wel voor minder overhead maar je kunt uiteindelijk minder agressief optimaliseren denk ik.

TM is voor Mozilla erg belangrijk: het maakt niet alleen websites sneller, maar kan de browser zelf ook een performance boost geven omdat plugins en Firefox zelf (gedeeltelijk) in JS geschreven zijn. (TM zal in 3.1 echter enkel geactiveerd worden voor websites, nog niet voor de browser zelf)

[Reactie gewijzigd door user109731 op 24 juli 2024 16:44]

[Dannydekr]

Even een belangrijke vraag, moeten skins voor 3.0 aangepast worden?
In dat geval heb ik veeeel werk te doen namelijk

[Mike-RaWare]

Ik denk dat deze pagina uw vraag kan beantwoorden.

[Dannydekr]

Gelukkig minimale aanpassingen,, ty voor de link.

[dupondje]

Beter uitstellen dan een brakke versie te releasen!

[Verwijderd]

Ach... ik werk al tijden met de nightly's/beta's van Firefox 3.1. Nog geen enkel probleem tegengekomen. Wat hier het probleem is zijn voornamelijk regressies ten opzichte van de Javascript engine in Fx 3, maar daar merk je als eindgebruiker niets van.

Bedenk wel, het is makkelijk om nou af te geven op Mozilla vanwege het wederom uitstellen van een beta release, maar:

• Firefox 3.1 heeft nooit een officiële roadmap gehad.
• Bij andere browserbouwers zou er niet naar buiten komen wat de daadwerkelijke reden is. Daar wordt alleen een vertraging van een paar weken gemeld. Dat is een voor- en nadeel van Mozilla's openheid.

[FireDrunk]

Maar we wachten wel met smart
Ik hoop dat ze aan Opera kunnen tippen met hun nieuwe features

[stephenophof]

Hmm.. Ik ben wel benieuwd wat Opera nou zou speciaal maakt als browser.
Ik gebruik Internet Explorer 8, Firefox 3.1, Chrome 1.0 en zo nu en dan eens Safari, maar ik vind Opera helemaal niks. Nu ben ik wel benieuwd wat jij er nou zo speciaal aan vindt

[Reactie gewijzigd door stephenophof op 24 juli 2024 16:44]

[kidde]

Mijn gok zou zijn: Dat je een feature-rijke / bloated* browser hebt die toch redelijk snel is en niet aan elkaar hangt van brakke extensies die conflicten gaan lopen geven.

*Afhankelijk aan wie je het vraagt en wat je ref. is.

[Little Penguin]

Ondanks het feit dat ik de Acid-testen belangrijk vind, ben ik wel van mening dat je er ook weer geen "browser-benchmark" van moet maken...

Het doel van de Acid-testen is om browsers de diverse features allemaal hetzelfde uit te laten voeren/weer te geven.

Zolang de browsers dit ook op redelijke termijn t.o.v. het verschijnen van doen ben ik ruim tevreden.

Overigens zijn er verschillende manieren om de testen te "halen", 1 van die manieren is "enkel die features implementeren" die je nodig hebt voor het halen van de test.

Gelukkig doet men dat bij Mozilla niet en kijkt met vooral naar het (vrijwel) geheel implementeren van de standaarden - nu doet Opera dat ook wel hoor...

[Verwijderd]

In sunspider, v8 en dromeao wordt Opera anders toch flink ingehaald door de concurrenten. Bovendien alleen een alpha van Opera 10 haalt Acid3.

[ytsmabeer]

In reallive merk ik dat Opera nog steeds sneller is, ookal is hij langzamer in de testen

[Verwijderd]

Zullen we de subjectieve discussie achter ons laten en ons beperken tot objectieve meetresultaten?

[Faiths_Sands]

Opera 10 is nog in alpha in die test, de rest is al in de bèta en dus waarschijnlijk al verder geoptimaliseerd. Verder is het een test die alleen gericht is op een bepaald deel van waar een browser voor dient, dit is ook waarom ik de Acid3 test nou niet echt heel belangrijk vind.

Het is natuurlijk leuk als je voor beide testen een hoge score haalt en het laat zien dat je je best doet om snelheid en compatibiliteit na te streven, maar het betekent niet dat je de beste/snelste browser hebt, dat zal in de praktijk moeten blijken.

Hiermee wil ik niet de resultaten van die test minder belangrijk maken, er blijkt toch uit dat er veel vooruitgang wordt geboekt op JS-gebied.

[SuperNull]

Ik draai de alpha van Opera 10 omdat dat de enige versie is die native is voor Linux 64 bit.
Het is echt nog nooit gecrached en werkt supersnel. Merkbaar sneller dan FF3.0.
Ze hadden het net zo goed een rc kunnen noemen. Ik ben echt zeer tevreden.

[Verwijderd]

deze meetresultaten zijn voor javascript. er is meer op het web dan enkel javascript.
ik merk ook dat opera behoorlijk wat sneller draait dan firefox, hoewel ik voornamelijk die laatste gebruik.
in opera zit standaard meer functionaliteit dan in firefox, als er addons op firefox worden geinstalleerd wordt dit trager. Een "naakte" firefox (zonder extensions) draait misschien sneller dan een naakte opera, maar dat interessert mij persoonlijk niet: ik gebruik firefox altijd met bepaalde extensions die ik onmisbaar acht.

[Verwijderd]

Dit is alleen javascript, een browser bestaat uit en doet een groot aantal andere dingen...

[THID]

ohja, en Acid3 is echt het benchmark voor de gewone gebruiker, hahaha, kom op zeg, pagina's worden goed weergegeven en dus is FF een prima browser, hoe komt iedereen toch bij die onzinnige acid3 test, leuke test, maar niet meer dan dat

[roy-t]

Haha standaarden, pagina's worden in IE6 ook goed weergeven, en dat is dus een prima browser!

V/a Firefox3 weet ik het niet, maar Opera was iig t.o.v. Firefox2 een stuk sneller, maar dat doet er niet echt toe tbh. Het gaat om de voor jou meest fijne browser.

In mijn geval is dat toevallig ook Opera, in jouw geval waarschijnlijk FF. Wat maakt het uit?

[Verwijderd]

Als iedereen had gedacht zoals jij, dan hadden de websites er nog steeds statisch uitgezien met frames en GIF-knoppen

Gelukkig zijn er wel mensen die vooruit denken. De Acid3 test is geschreven met volledig bleeding edge correcte code, die de meeste browsers nog niet ondersteunen. Over een paar jaar zal iedereen er lacherig over doen omdat alle browsers het zonder meer ondersteunen, net zoals dat Internet Explorer tegenwoordig zelfs de Acid2 test correct rendert.

[Verwijderd]

Omdat Firefox de test niet doorstaat of heb je daar nog echt een argument bij?

[Simon Verhoeven]

In zekere zin is het wel waar.
Acid2 is nog redelijk representatief voor de gemiddelde site, acid3 al heel wat minder.

[Verwijderd]

@Simon Verhoeven

Juist niet zou ik zeggen... Acid3 is een veel uitgebreidere test die daadwerkelijk goed geschreven code test. Acid2 test voornamelijk foutafhandeling.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 16:44]

[Verwijderd]

Dus "goed geschreven code" is meer representatief voor de gemiddelde site dan foutafhandeling? Ik denk dat je het web iets te positief voorstelt.

De Acid tests zijn op zich erg leuke tests. Ze leggen telkens de lat wat hoger voor browsers. In elke nieuwe Acid test zitten leuke features die je eigenlijk al lang had willen gebruiken, maar niet kan omdat de browsers het niet ondersteunen. Het is dus ook logisch dat de derde Acid test niet wordt gehaald door de huidige browsers (Opera incluis), anders zou de test de lat te laag hebben gelegd.

[Verwijderd]

Op welke info/statistieken baseer je deze uitspraak? Ik vind Opera vele malen fijner in het gebruik dan FF.

Ik ben trouwens absoluut geen 'fanboy". Getuige het feit dat ik momenteel Chrome gebruik.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 16:44]

[mphilipp]

Laat ze eerst maar eens de memory leaks oplossen. Ik heb nu 3.0.5 en die is erger dan de versie daarvoor, die eigenlijk al een verbetering was. Ik heb het spul altijd aan staan, en om de zoveel tijd moet ik mijn browser afsluiten omdat ie gewoon 60% cpu pakt en een hoop geheugen. Heel irritant.

[Jack Flushell]

Ik heb nu 3.0.5 en die is erger dan de versie daarvoor, die eigenlijk al een verbetering was.

Iets klopt hier niet...

[mphilipp]

In Jip&Janneke taal: 3.0.5 is slechter dan de versie daarvoor (V3 denk ik dan). De versie die dààr weer voor zat, was helemaal een drama. V3 was dus in eerste instantie een verbetering, maar op een of andere manier hebben ze dat weer tenietgedaan in 3.0.5.

Valt niet mee, hè?

[Verwijderd]

Die ervaring heb ik helemaal niet. Ik heb de browser altijd aanstaan, en merk niks van memory-leaks. Misschien hangt het ervan af wat je ermee doet?
Maar als dat zo is, dan is het een slechte zaak die direct reparatie behoeft. Ook dient men te kunnen verklaren van waaruit de memory-leaks ontstaan zijn.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 16:44]

[mphilipp]

Ik weet niet beter dan dat FF er niet goed tegen kan als ie 24/7 aan staat (al sinds 2.0). En ik kom niet op rare sites ofzo: t.net, nu.nl, gmail zijn bv de sites die zeg maar permanent een tabje open hebben.

Ik ben echt niet de enige, want Mozilla heeft er zelfs een punt van gemaakt om dit te verbeteren. Het is een bekend probleem. De vorige versie was wat beter, maar bij 3.0.5 heb ik zelfs regelmatig een crash. Ongetwijfeld ligt het aan de sites die ik bezoek, maar dat moet natuurlijk niet kunnen. Ik verdenk er de flash ellende van dat ze leaks veroorzaken. Die lui die dat soort prutsdingetjes (reklames voornamelijk) maken lijken me nou niet van die types die heel netjes programmeren en erop letten dat ze alle shit netjes opruimen achter zich. Want ik kom niet op rare sites met spelletjes of dat soort ellende. Niet eens pornosites....

[mindcrash]

Ik verdenk er de flash ellende van dat ze leaks veroorzaken. Die lui die dat soort prutsdingetjes (reklames voornamelijk) maken lijken me nou niet van die types die heel netjes programmeren en erop letten dat ze alle shit netjes opruimen achter zich.

Uhm... Adobe zelf staat er ook om bekend dat de Flash player zélf al behoorlijk wat memory leaks veroorzaakt, ook al wordt er in de AS code netjes aan Garbage Collection gedaan... voorbeeldje? voorbeeldje. En nog een voorbeeldje. En hier zullen vast wel meer voorbeelden tussen staan.

De schuld dus puur bij Flash designers cq. AS developers neerleggen vindt ik eigenlijk niet echt netjes...

[Reactie gewijzigd door mindcrash op 24 juli 2024 16:44]

[mphilipp]

Ach, het zal me worst wezen aan wie het ligt. Ik hoop dat je snapt dat ik geen onderzoek kan gaan doen naar waar het precies zit. Ik ga over het 'end-effekt' en dat is dat ik die browser na zoveel uur moet herstarten. Punt. Meer weet ik niet. Ik heb een vermoeden, maar meer ook niet.

En programmeurs van advertentie-ellende krijgen van mij niet zoveel credits op voorhand (een heerlijk vooroordeel, maar ik haaaaaaat reklame en iedereen die ermee te maken heeft). Ik heb nooit de totale flash community aangesproken, dus trek te tenen maar weer in.

[Spidey]

Ik gebruik al enkele maanden de 3.1 beta in OSX. Heel sporadisch een vastloper, maar voor de rest werkt de huidige beta naar behoren.
Ik hoop wel dat het opstarten in een volgende beta wat sneller gaat.
Ik kijk dus ook uit naar de eerstvolgende release....

[xzaz]

Inderdaad dat sommige makkelijk zijn op te lossen:

475100 blo P1 All [e-mail] NEW Change name to "Firefox 3.1 Beta 3" for official branding

https://bugzilla.mozilla....-1=blocking-firefox3.1%2B

[StM]

Dat ticket is er altijd en wordt door de releasemanager net voor de taging uitgevoerd Puur iets symbolisch eigenlijk.

[Reactie gewijzigd door StM op 24 juli 2024 16:44]

[Vordreller]

Lijkt mij goed dat ze het uitstellen.
De fouten moeten zo snel mogelijk uit de code gehaald worden, want anders riskeer je dat toekomstige applicaties steunen op de fouten van de oude code. Als die eenmaal correct komt te werken, heb je ineens een hele resem applicaties die niet meer gaan werken.

[Verwijderd]

Hulde voor Mozilla dat ze de release liever uitstellen dan suboptimale/buggy code publishen.