Firefox 4 second beta hits minor delay
All good things comes to those who bait?
Customer Success Testimonial: Recovery is Everything
Mozilla has delayed the second beta release of Firefox 4 by about a week.
The open source browser maker had tentatively planned to sling out Firefox 4 beta 2 late last week. However, Mozilla has now pushed that release back to Thursday, 29 July.
“Hi! We're glad you're interested in Firefox 4 Beta 2 - it's not quite ready yet. Our candidate builds (FTP links below) are still going through quality assurance tests,” reads a note on Mozilla's releases wiki.
A third beta is still on track for 6 August, according to the outfit's schedule.
Earlier this month the first beta of the next iteration of Firefox arrived. Mozilla said it had built so-called “crash protection” into the pre-release version of the surfing tool. It has been working hard to address the browser's stability, which some users have complained loudly about.
Underlying code in that beta included an HTML5 parser, called WebSockets, that allows developers to create yet more real-time integration for the Web2.0 wasteland, as well as IndexedDB for web apps to use structured storage. ®
COMMENTS
Maybe im the only one...
... but all i want from a browser is for it to be secure, to be able to run the sites i want to visit smoothly, for it not to be a resource hog and for it not to be a bloated pile of crap! Is that too much to ask?
I dont need to be able to integrate a million piles of web2.0rhia per page, or have a thousand tabs open, or any of the other bloat inducing excesses that keep being introduced in Firefox recently.
Here's an idea, add those things as add ons which a person can download to customise their firefox experience, and leave the basic functionality (and size and memory usage) as low as possible so that those of us who dont give a flying f*&k about Stephen Fry's latest Twittergasm can just use Firefox as a browser and not have to sacrifice half our system performance to view a single bloody page!!!
[/End Rant]
What?
Netscape / Mozilla has only ever used multi-process for some crypto and that was to avoid some licencing issues that were later resolved.
Traditionally for plugins they have run in-process with some system traps to try and cope with certain kinds of recoverable exceptions. The reason they plugins run in-process is because its incredibly difficult to run them out of process. For starters, plugins can be scriptable so JS calls have to be marshalled in both directions, accounting for issues like recursion. Then there is the general issue of dealing with unresponsive / dead plugins. How do you know when the plugin is dead / unresponsive as opposed to merely busy? How do you deal with plugins which are firing possibly hundreds of events out via callbacks? How do you deal with WINDOWLESS plugins where the plugin expects to draw directly into the HTML view? How do you feed the plugin with data from a URL while keeping your cache consistent and correct etc.
Mozilla feels it has resolved most of these issues but just ranting away as you did shows you have no understanding of why things are the way they are.
Um
"Underlying code in that beta included an HTML5 parser, called WebSockets,"
I don't think 'WebSockets' is an HTML5 parser. It's one of the new technologies under the 'HTML5' banner.
I guess you meant something like "...included an updated HTML5 parser and support for WebSockets..."
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring
