Firefox 4 Beta 8 Up

An anonymous reader writes "Mozilla has released a new beta of Firefox 4 this morning. Originally intended as a quick update for the feature-complete Beta 7 release, the new Beta includes 1415 bugfixes, a fine-tuned add-ons manager, improved WebGL support as well as URL bar enhancements."

Re:The only question I have is

[vlm]

There is a reason people have been calling FF bloated lately. This is without any addons, plugins (besides maybe Java), or themes or any crap built into FF.

34.7 megs? I can only run 120 FF processes on my main desktop then. Bummer. Hmm, that would be 12 across and 10 down.

Only things that matters to me are:

Adblock plus
Firefox sync
firebug
flashblock
ghostery
remove-it-permanently
Noscript

once I can get all that cross platform, I'm ready to switch. I'll put up with anything else, as long as those addons work.

Re:The only question I have is

[0123456]

NTFS is a journaling file system. It is unlikely that a system crash would cause data loss on anything that has already been written to disk.

Perhaps you should tell that to the many, many, many people Cc-ed on the infamous 'Windows crashed and ate my bookmarks' Mozilla bug.

And yes, it happened to me several times: any time XP blue-screened with Firefox running I'd find my bookmarks had gone after the reboot.

Re:Will it support languages other than JavaScript

[BZ]

> Will it finally support languages other than JavaScript for client side programming?

No.

In fact, we're _removing_ such support. We supported using python for chrome (Firefox browser ui, not google's browser) programming for years, and no one used it. It's just a performance drag on the javascript and C++ side of things, so it's being removed.

The fact is, supporting multiple languages in a single runtime without leaking and without nasty performance hits on both is not really all that feasible. Given that, and the near-zero amount of actual use such functionality would get, based on our experience with chrome, it's not worth building it in....

Re:The only question I have is

[YttriumOxide]

After reading your post I did a very quick test in .NET using System.IO.File.Open :

• When opening a file as read only and failing to close it, there is no effect.
• When opening a file as read/write and failing to close it, there is no effect.
• When opening a file as read/write, writing a little bit and then failing to close it, the little bit that was written is all that remains.

Repeating the test with a FAT32 filesystem, I had the following results :

• When opening a file as read only and failing to close it, there is no effect.
• When opening a file as read/write and failing to close it, there is no effect.
• When opening a file as read/write, writing a little bit and then failing to close it, the little bit that was written is all that remains

So, my tests showed the same results... I then tried System.IO.File.AppendAllText to append large amounts of data to an existing text file and deliberately crashing it before it finished.
Under NTFS, the file was zeroed. Under FAT32, the file contained the original data plus part of what I was writing (I assume up to the point that it had written when I crashed it).

Note that I can't say if this is a fair test since I don't know what underlying stuff .NET is actually calling, but it's the only dev environment I have on my Windows system (which is my work box)). However this test definitely shows a difference between NTFS and FAT32 in some circumstances. Not where I first expected, but definitely somewhere...

Perhaps it'd be fair to blame both NTFS *and* Firefox for this one - Mozilla could have found a better way to write the data after all (which they eventually did by switching to a database, but I get the feeling they could've achieved it more simply in a minor update beforehand)