Slashdot Mirror

← Back to Stories (view on slashdot.org)

Firefox 4 Beta 8 Up

Posted by CmdrTaco on from the not-the-fish dept.

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."

17 of 385 comments (clear)

  1. The only question I have is by Rosco+P.+Coltrane · · Score: 5, Insightful

    Will the next version of Firefox (whatever version it may be) be slower? Because quite frankly, FF has become a giant turd in that respect, so much so that, although I love it, I'm considering alternatives on my lower-end machines...

    --
    "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
    1. Re:The only question I have is by Wordplay · · Score: 5, Informative

      http://weblogs.mozillazine.org/asa/archives/2010/10/are_we_fast_yet.html

      That benchmark is a bit old (two months ago), but you get the idea.

    2. Re:The only question I have is by Anonymous Coward · · Score: 5, Insightful

      There's more to a browser than rendering and Javascript performance. Firefox has become a hard disk hog. It almost continually writes to disk, which can be very slow, for example on netbooks with first generation SSDs or when you keep your profile on a USB stick (portable Firefox). Worst of all, when it does write to disk, the whole browser locks up. It's barely usable on netbooks for that single reason. You'd think that nothing a browser does could justify writing or reading megabytes of data almost every minute. That's still what happens. (No, extensions or plugins are not involved.)

    3. Re:The only question I have is by augustm · · Score: 5, Informative

      It has been a turd since this summer, mostly due to the bug in the SQL code which
      killed interactive performance. It was repaired this week and should make beta9. It
      is also in recent 3.6 builds so mainline firefox is almost unbearable.

      Meaningless javascript benchmarks are not very useful for this sort of bug- which
      gives 10 second hangs when working with history or bookmarks.

      Bug number 595530

    4. Re:The only question I have is by couchslug · · Score: 4, Funny

      Given the burden of the many ad-ons I run, I'm not sure which is fucking up, the browser or the add-ons.

      One nice thing about running 8GB RAM on a 32-bit system with PAE enabled is that when FF gobbles memory it maxes out at 4GB!

      I'll keep it for the add-ons. RAM is cheap.

      --
      "This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
    5. Re:The only question I have is by damien_kane · · Score: 4, Informative

      The simplest solution is to turn of hdd-caching, but a more in-depth solution is to actually setup a RAMdrive and point your FFCache, IECache, and Windows Temp directories at that.

      Unfortunately setting up a ramdrive is above the general public's scope of ability.

    6. Re:The only question I have is by 0123456 · · Score: 4, Interesting

      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.

    7. Re:The only question I have is by Anonymous Coward · · Score: 5, Informative

      You may wish to re-try this on FF 4. There has been significant work put in to reducing disk access in Firefox:

      There is also a tracking bug for bad I/O patterns available, so you can see what they're up to.

    8. Re:The only question I have is by 0123456 · · Score: 3, Insightful

      Then why doesn't it happen with other browsers?

      IE writes to individual files per bookmark, whereas Firefox used to write to one big flat text file which could be several megabytes in size. Chrome presumably learned from Firefox and writes to some kind of database?

      Also, any database Firefox might be using it still going to be sitting on top of NTFS and thus prone to the same problem if it really is the fault of the file system.

      Sqlite syncs three times every time you update the database, and uses its own journaliing to allow it to recover from corruption.

      Sounds more like a bug in Firefox than one with NTFS.

      Then why didn't it happen on other file systems? It happened to me often enough that I switched that partition to FAT32 in the end, which could recover from a crash without randomly deleting files.

      In the real world it's an interaction between how Firefox was updating its bookmarks file with poor design on Microsoft's part. Firefox would be writing the file numerous times while you were browsing the web, and somehow NTFS would truncate the file to zero bytes if it crashed at the wrong time during that process.

      And I'd also add that one time I had NTFS delete a _two gigabyte_ file that I was downloading from the Internet when the power went out. I suspect the problem is somehow related to files which have been created but not closed when the operating system crashes.

    9. Re:The only question I have is by YttriumOxide · · Score: 3, Interesting

      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)

      --
      My book about LSD and Self-Discovery
      Also on facebook as: DroppingAcidDaleBewan
  2. URL Bar by TheL0ser · · Score: 5, Insightful

    as well as URL bar enhancements

    If by "enhancements" they mean "throw the awesomebar out a window", I'm all for it.

    Yes, part of that is resistance to change, but part is from my first experience involved typing a URL and seeing results getting pulled from the middle of a page's title that had nothing to do with what I wanted.

    1. Re:URL Bar by rudy_wayne · · Score: 5, Insightful

      as well as URL bar enhancements

      If by "enhancements" they mean "throw the awesomebar out a window", I'm all for it.

      As a long time Firefox user, this has been one of the most infuriating things, as they continually remove or fuck up useful features. The Mozilla developers seem obsessed with changing things just to make them different. The list of things they have eliminated or made less useful is almost endless. I'm sure they can give us all sorts of rationalizations for what they do, but it's all bullshit. Making things less useful is not an improvement.

    2. Re:URL Bar by kripkenstein · · Score: 5, Informative

      as well as URL bar enhancements

      If by "enhancements" they mean "throw the awesomebar out a window", I'm all for it.

      As a long time Firefox user, this has been one of the most infuriating things, as they continually remove or fuck up useful features. The Mozilla developers seem obsessed with changing things just to make them different. The list of things they have eliminated or made less useful is almost endless. I'm sure they can give us all sorts of rationalizations for what they do, but it's all bullshit. Making things less useful is not an improvement.

      I'm a Firefox developer. I understand that it can seem that way, but trust me, a lot of thought goes into each change we make. I'm not saying we are always right, or even always right for most people - nobody's perfect. But I do think that overall we do a good job, in picking what to change, and for the specific stuff you dislike, most of it should be configurable through prefs.

      But, I realize that doesn't help you, and I'm sorry that some of our changes are not to your taste.

    3. Re:URL Bar by GreatBunzinni · · Score: 4, Informative

      Yes, awesomebar IS that infuriating. Paralyzed by seeing options, no, but give us the option to turn off behavior we don't like. Is it THAT hard to do?

      No, you only need to hit "edit"->"Preferences"->"Privacy" and in the "Location bar" section, where it says "when using the location bar, suggest:" just select "Nothing" from the dropdown menu.

      Now that you know that, if it is that infuriating then how come you failed to even look at Firefox's preferences to disable it?

      On the side note, I love the awesome bar. I configured it to display only bookmarked links (that option is also available in the dropdown menu I mentioned) and now, instead of clicking through multiple menus or, *ghasp*, use a search engine, I just hit Ctrl+L, type a couple of keys and voila: I'm opening the link. You say infuriating? I say godsend.

      --
      Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
    4. Re:URL Bar by Anaerin · · Score: 4, Insightful

      Isn't it ironic, that the feature that you are so hateful of in Firefox (The awesomebar) is a lesser version of Chrome's "Omnibox", that not only searches your history and bookmarks (Something that you espouse so much hate over) but the web as well. Yet you don't seem to mind Chrome's history/bookmark/web search bar near so much as you do FireFox's history/bookmark bar.

  3. Re:Is "Beta" an appropriate label? by revlayle · · Score: 4, Insightful

    If it still has bugs and needs more testing before a stable release (or even Release Candidate), then yes, Beta is MORE than an appropriate label. (Methinks, people these days don't really understand what beta software is? Hell, may I don't, anymore.)

  4. Re:Will it support languages other than JavaScript by BZ · · Score: 3, Interesting

    > 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....