Slashdot Mirror

The extension doesn't break. Extensions have an inbuilt version number specifying which versions of Firefox they are compatible with. When you download an extension, it has an internal specification saying, "I work on Firefox 1.5 - 3b4". When you upgrade to Firefox 3b5, your extension, like a good citizen, disables itself, because it has not been tested on your new version of Firefox, and could potentially cause massive problems in unforeseen ways if there was a core change in how Firefox behaves. It is up to the extension developer to do due diligence in checking his/her own extension, and then if no problems crop up, bump the version compatibility number on their extension and re-release, often with no other changes to the core code of the extension itself. This system exists to protect your data. If you do not like it, you can turn this protection off, see here.

Like a lot of things in Firefox, you can turn it off if you really don't like it. To disable the awesomebar and just have the old URL autocomplete, you'll need to add a pref. I confess, I didn't much like it at first, but the behaviour learning and improved search introduced in 3b4 has sold me on it. Any who... to turn it off:

Add the boolean pref browser.urlbar.richResults and set it to false.

This pref is only checked on startup, so youâ(TM)ll need to restart Firefox for it to take effect. More information about this pref can be found here. More info on setting prefs through about:config starts here

Like a lot of things in Firefox, you can turn it off if you really don't like it. To disable the awesomebar and just have the old URL autocomplete, you'll need to add a pref. I confess, I didn't much like it at first, but the behaviour learning and improved search introduced in 3b4 has sold me on it. Any who... to turn it off:

Add the boolean pref browser.urlbar.richResults and set it to false.

This pref is only checked on startup, so youâ(TM)ll need to restart Firefox for it to take effect. More information about this pref can be found here. More info on setting prefs through about:config starts here

Firefox will not crash due to a badly implemented web site. Firefox will crash only due to a bug in Firefox or software that is running inside the Firefox process that you have installed on your computer, such as an extension, plugin, driver, or the operating system itself, or in some circumstances, a hardware problem. Is Firefox crashing often for you? If so, follow this advice.

There was recently a long discussion on this:
http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/4f1595449bf94cd2/

preed had some things to say in his blog as well:
http://weblogs.mozillazine.org/preed/2008/03/what_does_god_need_with_a_star.html

>Firefox and IE only just now pass Acid 2 in their *development releases*.

Ah, maybe you actually investigate and learn something about this before making ridiculous assertions of fact. Firefox passed Acid2 in a "development release" (dbaron's reflow branch builds absolutely were available as "development releases") precisely two years ago and trunk builds were passing in early December of 2006.

I don't know about your definition of "just now" or your definition of "development releases" but it seems to me that you're way off on at least one of those.

- A

Mozilla wants me to update from 2.0.0.12 to 2.0.0.13. Is there any reason I shouldn't just go to 3.0 Beta 5?

Apparently, this was related to an outdated list of phishing sites, causing the browser to try to download updated sites in one bite. See here: http://weblogs.mozillazine.org/asa/archives/2007/11/firefox_3_beta_1.html. It hasn't happened to me in months, so I think it's been fixed.

with Firefox open about:config search for image_animation_mode and set to none

Now that's just silly. Mozilla developers never flamed anyone for saying leaks exist in Firefox. In fact, they said that of course Firefox has memory leaks. On the other hand, even with the leaks it seems to use less memory than other browsers. So saying it's got horrible memory leak problems, far worse than other browsers, will probably get you flamed. But simply saying it has memory leaks is an objective, verifiable fact that no reasonable person should disagree with.

No, iTunes is not Webkit. That is a misunderstanding which is there for years.

Mr. Hyatt got a blog entry related to it
http://weblogs.mozillazine.org/hyatt/archives/2004_06.html#005666

"Just to clear up a common misconception, iTunes does not use WebKit to render the music store. What you see when you visit the iTunes music store may look "web-like", but it isn't HTML, and it isn't rendered by WebKit."

So what are the "half a hundred things" that are bundled, assuming you mean applications, not default preferences (which, to me, are very different things). If you download Firefox from mozilla.com, you get Firefox, that's it.

If you don't want the update page to show up after a successful upgrade, just set the value for browser.startup.homepage_override.mstone to "ignore".

You can find benchmarking results for a somewhat different test with Firefox 2 and Firefox 3 using tabs instead of windows. They still show the same end result: Firefox uses less memory than other browsers.

You can find benchmarking results for a somewhat different test with Firefox 2 and Firefox 3 using tabs instead of windows. They still show the same end result: Firefox uses less memory than other browsers.

I started Firefox on two different computers Tuesday afternoon with those exact four pages open in four different tabs. Computer A is an HP Pavilion running Windows XP Home and Firefox 3.0b5pre build 20080306. Computer B is a Dell Optiplex running Windows XP Pro and Firefox 2.0.0.12. When I first started the computers, Firefox was using 67 MB on computer A and 70 MB on computer B. After leaving Firefox running all night (more than 12 hours), Firefox was using 80 MB on computer A and 91 MB on computer B. That is an increase of 13 MB on computer A and 21 MB on computer B. It's possible that that amount of memory increase is due to a memory leak, but most often small increases are due to the effects from caching and fragmentation. I notice that the pages do have dynamic content, which would require loading new content and allocating and deallocating memory, so you would have to expect a certain amount of memory increase after hours of use. These are not static HTML pages.

The signature of a memory leak is memory usage increasing without limit. What happens when those sites are open for a week? Does memory use continue to increase to 170 MB? If so, I wouldn't be able to explain that degree of memory use increase by caching and fragmentation, and I'd have to say it looks like a leak.

The bottom line is that the vast majority of Firefox users don't have a particular problem with memory usage. If you do, then either (1) you are experiencing a bug in Firefox, and you should find a way to reliably reproduce a problem so it can be fixed, or (2) you are having a problem on your computer, and you should follow the advice in the MozillaZine Knowledge Base to fix your problem.

I can't figure out quite what they mean by "Improved in Beta 4!" ... "Integration with the Mac". Every single one of the little non-Mac-isms that FF3b3 had are still there, and there are some rather obvious new foul-ups.

The most obvious is the Back button, which looks like the crack baby of a Star Trek badge. And if you right-click Customize to try to fix it (ignoring how awful the toolbar editor is), you'll notice that the other styles are hardly any better. In fact, if you choose Show: Text, then you don't even get a Back or Forward button: they turn into menus *only*.

(Remember when we thought "Cocoa widgets" meant they'd be using native Cocoa widgets? Nope, it "really only means that the widget code is (mostly) written using the Cocoa API as opposed to the Carbon API". You still need to get Camino if you want a toolbar that uses real Mac toolbars and whose buttons actually work.)

Firefox 3 beta 3 had some neat improvements over Firefox 2, so I was hoping FF3b4 would clean up some of the little glitches (which I've been reporting for the past month or so). Instead, they fixed zero of the Mac UI glitches, and broke some obvious things that were working fine.

FF3b4 is the software equivalent of Mozilla developers taking a giant dump on the Mac. If I'm not noticing "drastic" (their words, not mine) improvements in speed and memory use, I'll probably go back to FF3b3 tonight. I'm fine with beta-testing software, but only if the developers in question are going to go to some effort to make the software better for me. Tweaking the allocator while breaking the UI does not count.

Just see if you're running any of the extensions known to have bad memory leaks or one of the extensions that cause leaks in Firefox. If you're not running one of them, you'll probably be safe. For brave souls wishing to track down which extension is leaking, I suggest creating a new profile, then adding extensions one-by-one.

That shouldn't be happening. Either that's a bug in Firefox, in which case you should give the exact steps to reproduce the problem so it can be fixed. Or it's a problem on your computer, in which case you should follow the advice in the Knowledge Base to fix it.

For more discussion on the new UI themes and changes, there's a thread going on at mozillaZine about it.

The icons will grow on you after a while, and they're still making refinements and changes to the icons and backgrounds. Personally, I think the Back/Forward buttons are pretty decent, it's the rest (Reload/Stop/New tab/window) that looks a little too simple and out of place. Can't say I really agree with using different themes across different Windows versions too, this has to be the first application I know that tries that.

To put it bluntly: You're sh*t out of luck.

See here for the discussion that basically goes:

Us: This is terrible behaviour and hugely inconsistent. It will confuse novice users with inconsistency and searching in an address bar and it'll annoy power users who used to be able to consistently locate the places they wanted to go based on the URL (which they remembered and which remained consistent). If we wanted to search then we'd search. Yes, it can be useful in some situations, but if we know what we want to type then we don't want the browser thinking it is better than me and incorrectly second-guessing what we want.
Them: Everyone searches, and it learns. Searching is the future, so we're going to make you search.

The two sites I visit most at work are Slashdot and the BBC news (news.bbc.co.uk). What used to turn up top for "ne", "new" and "news"? The BBC news, because I wanted to go there and it matched what I typed. What turns up now? Slashdot because of "news for nerds" in the title. It needs huge amounts more weighting on URL starts than titles, but they don't seem willing to change it.

The other one that really annoys me is one of my sites. I could normally go to "sk" and hit it as first result, but now I've got to type even more of it and it doesn't make it to the top until after I've done the whole domain (because the domain is in the title of another page that always turns up top).

Actually, I believe Firefox 1 was used, albeit with hacks in order to work around the known CSS bugs. Sorry I can't find any corroborating source; I don't remember where I read this (if I did at all), and Googling only turns up a recent post on Reddit that goes undisputed by "Hixie", who seems to be Ian Hickson.

For the case of Acid3, calculations were probably easier this time around, since Javascript is simpler to compute separately. I'm not intimately familiar with the tests, but it seems like their calculation would require far less coordination with a corrected rendering engine.

As a sister comment hinted, they don't know there are no bugs in the test. Development of Safari yielded a bug in Acid2 that was subsequently submitted and corrected (scroll to the bottom).

Firefox already supports session restore.

http://kb.mozillazine.org/Layout.spellcheckDefault

One thing you should do if you've had problems with Firefox 2 is create a new profile, whether you decide to stick with Firefox 2 or update to Firefox 3. In my experience in the MozillaZine forums, that one simple suggestion seems to fix most problems. There's lots of other advice for fixing problems in the MozillaZine Knowledge Base.

One thing you should do if you've had problems with Firefox 2 is create a new profile, whether you decide to stick with Firefox 2 or update to Firefox 3. In my experience in the MozillaZine forums, that one simple suggestion seems to fix most problems. There's lots of other advice for fixing problems in the MozillaZine Knowledge Base.

I ran Firefox 3 beta 3 on Windows for a week without closing it just recently. It was using 150 MB of memory, with a peak mem usage of 250 MB. Having to close Firefox every few hours isn't the typical Firefox user's experience. Firefox using 100-150 MB of RAM is typical, even when running for many days. It sounds like you're having an unusual problem if you're having to restart it every few hours. Perhaps you may want to follow some of the suggestions on the page I linked to.

Hmmmmm... Firefox looks like it uses less memory than other browsers to me. How would we see this "memory whore" thing you're talking about? Can you give me a site to go to that causes Firefox to use much more memory than another browser?

No, the back/forward cache is not going to use hundreds of megabytes fifteen minutes after you start the browser. It holds only up to the last eight pages you visited, for an average memory usage of about 32 MB. It sounds like you are experiencing a very serious memory problem that hardly any Firefox users experience. Typical memory usage is 100-150 MB on Windows.

It looks pretty lightweight to me, if by that you mean it consumes fewer resources than other browsers. On the other hand, if you've got a way to demonstrate Firefox being a pig (one that we can all see and confirm), we'd all love to see it...

You mean WebKit the open-source project? Yup, just like Microsoft...

http://weblogs.mozillazine.org/roc/archives/2008/02/platform_tilt.html

Disassembly shows these WK functions are mostly just wrappers around undocumented framework functions. The source to the WK wrappers is not available; the implementations are in a binary blob library that you download with the Webkit sources. It appears the sole purpose of closing the source to this library is to conceal the signatures of the undocumented framework APIs used by Webkit, presumably so that ISVs like us can't use them.

Yup.

No, sorry, neither I nor any Firefox developer has ever claimed that Firefox has no memory leaks. Certainly there are extensions with very serious memory leaks. Firefox has some leaks, too, but they are far more subtle than claimed. In most of the memory leak bug reports I've seen recently, you need a special debug build to determine that any memory at all is leaking. If you're seeing Firefox leak lots of memory, please do tell us how to reproduce the problem (it shouldn't be hard at all if the problem is as serious and widespread as you claim), and then developers can fix the problem. I'm asking because I'd like to help get the problem fixed, if there is in fact a problem. Don't you?

only way i think it can end up doing so is if you hit it with very high rez images on a single page...

http://weblogs.mozillazine.org/ben/archives/009749.html

it does not use it all, or at least not intentionally...

here is how 2.x does it iirc:
http://weblogs.mozillazine.org/ben/archives/009749.html

basically it looks at overall ram available and decide how many pages should be kept in ram to speed up history "browsing".

thing is that i think what one see is that this runs smack into how windows deals with swap. from what i recall reading, windows starts sending things to swap when the amount of used ram reach about 75% or so. and given how almost no program under windows share libs, that can happen pretty damn quick.

and in that environment, having firefox gobble ram isnt productive by a long shot.

and when one use that kind of environment long enough one start to mentally connect large amounts of ram used by a app with the whole system becoming slow because every time something happens things have to move in and out of swap. and this becomes something that stays with a person unless one goes about "untraining" that way of thinking...

this isnt some kind of attack btw, its just a observation about how our brains work. i keep hearing about people in some biz or other failing to grasp a new way of doing things because they are so used to doing it the "old way". i suspect our brain tries to do shortcuts by applying what it knows to something that appears similar (it saves time and energy when it comes to processing it), but when it looks the same but does not compute the same, it throws a error, and one have to go back to what the current way of doing things are a extension of, try it and see if it works or fails, and so on...

in the end one may well find that one have to relearn everything from scratch. the trick is to realize this before one waste time trying all those other steps. in a way, keep a open mind about learning. but as we age i fear that part of our brain shuts down, or at least is put on deeper and deeper levels of standby...

Short answer, maybe Long answer: If FF3 isn't using a processor specific optimization, you can always Download your own build, I like pigfoot's (scroll down) build for windows.

Ok parent shouldn't have been modded offtopic, as the linked article does compare different browsers, but anyway...

The benchmark is linked from here, nightly builds of Safari are available here, and a build of Firefox with this enabled is available here.

Actually that functionality exists in the Mozilla Suite as well as the built in Google translate. I dislike that fact that they have removed some of these features. For the record; there isn't an extension that was as functional as the "Translate" function that was built in the old Mozilla Suite (and SeaMonkey).

Here are your links for your request in Firefox w/out the use of an extension:

http://kb.mozillazine.org/Location_Bar_search
http://www.squarefree.com/2004/09/09/googles-browse-by-name-in-firefox/

Regards,
Anonymous Coward.

in this thread

I wish that the Mozilla folks would just enhance the Eudora program - like they were "supposed to do." Whine-ingly

It was also easy to set up virtual folders (based on search criteria) to associate your e-mail according to several criteria.

Thunderbird can already do this, see kb.mozillazine.org/Saved_Search. And the searches are pretty damn fast.

Emacs keybindings for Firefox. It covers most of the common use cases.

My typical memory-burning web surfing session is to go to Google News or especially to Fark.com, open up about 100 tabs of potentially interesting news stories, and then go read them one at a time, closing each one after I've read it. It's one thing to have the browser use lots of memory while I've got all the tabs open - but when I've finished with them all, and just have the original page back, or even hit "Home" to get "about:blank", the browser typically *still* has over 100MB of RAM and is often burning 20-70% of CPU.

I've never had Firefox use that much CPU, but many of those tabs you closed are still cached in memory (along with each of their histories) so they'll reopen really fast if you Undo Closed Tab. Closing the tabs does not necessarily mean they're going away. Changing this option in your about:config should keep that from happening (I think), but you'll also lose some of your session restore functionality. I have it on, and I've never had any of the problems you and a lot of other people have, but I hope this helps.

Actually, the perceived performance issues of Firefox mostly stem from the fact it's a single-threaded architecture running on a JavaScript+XML interpreter (XULRunner).

There is indeed only one thread handling the UI and DOM, but there are multiple threads. Network operations, file decoding and so on run in separate threads from the UI. MAking a multithreaded UI is quite hard; note that IE (at least 6, most likely 7 too) does that too, with the difference that you can have separate windows in different processes altogether; but then they can't talk to each other through JS.

The only time this architecture is really a problem ATM is when JS from a page sucks up CPU: it bogs down the whole UI.

Moving to a fully multithreaded architecture is a very hard problem, esp. for such a complicated application, with such complex interactions as a web browser. Every single little thing would have to be synchronised, with big deadlock risks at each turn.

The only possible approach is to divide work among threads such as there is minimal, well understood interactions between them. You can't for example just have one thread per window, because HTML+DOM+JS expect to be able to touch other windows from the same domain. You could divide processes by originating domain; that's what Apprunner does.
But then you have coordinate communication between the windows and the bookmarks, history and so on. Not too hard to do, but has to be weighed against the minimal gain.

Eventually, we will have to take advantage of many-cores CPU. That means that even DOM parsing will have to be multithreaded, for use on ultra low power 256 cores mobile cpus. Robert O'Callahan is working on this. But what you have in this case is a number of related threads with a very limited scope, and precisely defined interactions.

You can read more on these issues at his blog:

Parallel Dom Access
Night of the living threads

Actually, the perceived performance issues of Firefox mostly stem from the fact it's a single-threaded architecture running on a JavaScript+XML interpreter (XULRunner).

There is indeed only one thread handling the UI and DOM, but there are multiple threads. Network operations, file decoding and so on run in separate threads from the UI. MAking a multithreaded UI is quite hard; note that IE (at least 6, most likely 7 too) does that too, with the difference that you can have separate windows in different processes altogether; but then they can't talk to each other through JS.

The only time this architecture is really a problem ATM is when JS from a page sucks up CPU: it bogs down the whole UI.

Moving to a fully multithreaded architecture is a very hard problem, esp. for such a complicated application, with such complex interactions as a web browser. Every single little thing would have to be synchronised, with big deadlock risks at each turn.

The only possible approach is to divide work among threads such as there is minimal, well understood interactions between them. You can't for example just have one thread per window, because HTML+DOM+JS expect to be able to touch other windows from the same domain. You could divide processes by originating domain; that's what Apprunner does.
But then you have coordinate communication between the windows and the bookmarks, history and so on. Not too hard to do, but has to be weighed against the minimal gain.

Eventually, we will have to take advantage of many-cores CPU. That means that even DOM parsing will have to be multithreaded, for use on ultra low power 256 cores mobile cpus. Robert O'Callahan is working on this. But what you have in this case is a number of related threads with a very limited scope, and precisely defined interactions.

You can read more on these issues at his blog:

Parallel Dom Access
Night of the living threads

Actually, the perceived performance issues of Firefox mostly stem from the fact it's a single-threaded architecture running on a JavaScript+XML interpreter (XULRunner).

There is indeed only one thread handling the UI and DOM, but there are multiple threads. Network operations, file decoding and so on run in separate threads from the UI. MAking a multithreaded UI is quite hard; note that IE (at least 6, most likely 7 too) does that too, with the difference that you can have separate windows in different processes altogether; but then they can't talk to each other through JS.

The only time this architecture is really a problem ATM is when JS from a page sucks up CPU: it bogs down the whole UI.

Moving to a fully multithreaded architecture is a very hard problem, esp. for such a complicated application, with such complex interactions as a web browser. Every single little thing would have to be synchronised, with big deadlock risks at each turn.

The only possible approach is to divide work among threads such as there is minimal, well understood interactions between them. You can't for example just have one thread per window, because HTML+DOM+JS expect to be able to touch other windows from the same domain. You could divide processes by originating domain; that's what Apprunner does.
But then you have coordinate communication between the windows and the bookmarks, history and so on. Not too hard to do, but has to be weighed against the minimal gain.

Eventually, we will have to take advantage of many-cores CPU. That means that even DOM parsing will have to be multithreaded, for use on ultra low power 256 cores mobile cpus. Robert O'Callahan is working on this. But what you have in this case is a number of related threads with a very limited scope, and precisely defined interactions.

You can read more on these issues at his blog:

Parallel Dom Access
Night of the living threads

You would think there would be some 'legacy plugin support' for people to enable if they so desire.

Have a look here:
http://forums.mozillazine.org/viewforum.php?f=18

And did you read the actual comments to that A List Apart article? Almost every single one of them rejected the proposal. In fact, both Opera, Mozilla, Apple and Google have rejected it. As well as most web developers who have spoken up.

If you would only educate yourself instead of spouting uneducated nonsense...

In the mobile market, Safari is killing the competition by being bundled with the iPhone. When Mozilla 2 comes out, "Mobile Firefox" will compete in the mobile market, too. The competition is tough and getting tougher even in the mobile market where Opera has traditionally done best.

There are about 1.3 billion Internet users according to Internet Growth Statistics. That seems to add up to me. Firefox may have up to 150 million users by now. So where are all the complaints about web sites breaking with each release of Firefox? All I can see is lame "memory leak" complaints that no one can seem to verify.