AdBlock and Firebug are both know to cause memory problems in some cases. I believe this will, at least in part, be fixed in Firefox 4.0.1 - which was launched the other day I think (maybe you already updated to it). But even so, they are good first suspects. Firefox lets addons modify a lot of internal things, which makes useful addons like AdBlock and Firebug possible, but also gives them the opportunity to (easily) create memory leaks.
In general, though, my best suggestion would be to see how things are without *any* plugins or addons. Simplest way is to create a new profile, and disable plugins and addons in it. Then browse for a while and see how things are. Odds are, you won't see strange memory behavior, and then the question is, which addon or plugin it is, and you can reenable them one by one til you find the guilty one.
Long-term, most addons will probably become Jetpack addons, which is a model similar to Chrome's. That kind of addon is more limited in what it can do, but also unable to cause memory leaks. Aside from that, we are moving to a one process per tab model, also like Chrome, will will help narrow down which page is responsible for large amounts of memory being used, when that happens. In the short term, though, problems like yours are almost always caused by addons or plugins, and I apologize for the hassle, the best thing to do is to find which it is, as I said earlier.
If you prefer to change that behavior, it's easy to do - change browser.sessionhistory.max_total_viewers in about:config to 0. Then it won't cache pages. You will have slower loading of pages when you press back, restore recently closed tabs, etc., but if you would rather save that memory then that's cool.
In my personal experience, and also in surveys of Firefox users, the caching is almost always a good thing - it does not lead to any system slowdown, and does speed up the responsiveness of the browser. But that doesn't mean it's what everyone wants, and maybe your browsing habits are in a way that caching isn't a good idea - so the caching is configurable.
That sounds normal to me - going from 178MB to 223MB isn't unexpected. You probably have several pages cached, each taking a few MB. That, and things like the JS heap 'settle' on a slightly higher amount of RAM soon after load (and stay there), as they keep allocated pages held to not waste time reallocating them later. There is also some effect of memory fragmentation (which makes more memory appear to be allocated than has been).
An interesting comparison would be, to load those exact pages in Firefox and a few other browsers. They will probably show similar memory behavior, but if they don't, please let me know!
Thanks for the valuable feedback to the OP. Comments like this keep me coming back to Slashdot.
Out of curiosity, is there an option to turn on aggressive releasing of pages? It seems to me to be a good idea, but without being familiar (even remotely) with the source code and design perhaps there are reasons against this (if there is indeed no option to turn it on/off).
Cheers
You can simply tell Firefox to not cache anything by setting browser.sessionhistory.max_total_viewers to 0 in about:config. Then once you browse away from a page, it's memory will all be released. More details here
The problem with this is that pressing 'back' will mean a complete reload of the page you just left. At least in my experience, caching pages is almost always worth it (unless you have machine with very limited RAM).
Does that mean they weren't using a profiler before now??
That... actually explains quite a bit...
No, we use profilers;) In fact we have some valgrind - the awesome Linux profiling tool - devs working here.
Profile guided optimization is something else though. It is a special way of compiling and linking, that the compiler and linker use profiling information to know how best to optimize the code. So code that is used a lot is compiled with -O3 (the most optimizations), while code that is not used a lot gets -Os (to take less space), and so forth. This is a very useful technique that was not available on Linux until last year, and the news today is that Firefox now builds properly with it and there is a nice noticeable speed improvement for Linux users.
Install FF 4, browse a while, close all but one _blank_ tab and guess what? Firefox uses 7-800 MB _active_ memory.
Hi, I'm a Firefox dev. That sounds very bad. Can you please give some more details about how to reproduce it: Are you using a new profile? Are there any addons and plugins installed? What websites do you visit? And what specific Linux distro are you on?
Note that this might not be a bug: For example, if you visit a website that shows 200MB of images, then close that tab, then the memory is not necessarily freed. The reason is that the page stays cached, so that if you do 'History->Recently closed tabs' and open it, it will appear quickly. On a machine with lots of memory (most these days), that behavior tends to work better than releasing pages aggressively. However, if you aren't visiting websites with extreme memory use like that, then this might be an actual bug.
Getting back to your problem: With a new profile and no addons or plugins, we are unaware of a bug that causes anything like that. So I would be very grateful to you if you can point us to a bug we don't know about, so that we can fix it. If you give me steps that I can use to reproduce the problem (on my Linux machine over here),then you have my promise that I will l personally look into this and do everything in my power to fix it.
Though, maybe their way of doing it or updates in makefiles help maintainers of distributions to put better builds. I guess that's what matters, not their own build on web page.
Exactly, yeah. Most Linux users probably get Firefox through their distro, but the effort and patches that got this improvement done, will allow distros to compile in the same way and get the same speedup. If everything goes right, distros should be able to compile with these options and things will just work.
However according to Hommey, these new faster and less sluggish builds of Firefox for Linux will be available only from Firefox 6 onwards and we expect the first beta of Firefox 6 to available only by September - October 2011.
Note that you do not need to wait, if you are ok with running a Nightly build. Nightly builds are the latest code, so they are obviously less stable. But you can get this improvement right now if you want it.
Otherwise, you can wait just a few weeks and Firefox 6 Aurora will be released, which is somewhat more stable, and will include this code. (6 weeks later will be a Beta, and 6 weeks after that, a stable release.)
The example doesn't work. Also even if it did it would be "marking the first such scripting language alternative to JavaScript" only for people who want to restrict their website to Chrome users.
Which is a shame, especially as it is totally avoidable: It is possible to compile Tcl to JavaScript (using Emscripten), which would allow you to script the web using Tcl on any web browser and on any platform.
Disclaimer: I wrote Emscripten, sorry to pimp my own project. But if you are a Tcl hacker and want to compile it to JavaScript, please get in touch, I'd love to help.
I don't mean that innovation is bad. I was careful to clarify that before. And I further clarified that I did not mean to diminish in any way his work.
It is still a valid concern, that a new nonstandard protocol is being used to optimize a specific combination of super-popular website plus popular client software, as it puts all competitors at a disadvantage. The purpose of standards is to level the playing field.
And the purpose of innovation is to move us forward. You can - and should - still innovate, just not in this way, of running a nonstandard protocol in production. You can, instead, run the nonstandard protocol in part of the production code, either randomly assigned or opt-in. I would have no problem with that. I realize this may seem like a small difference, but it really isn't.
That node.js implementation is from 3 days ago. It probably isn't ready for production.
Right now, Chrome+google.com is the only production combination that benefits from SPDY. Simply because Google developed SPDY and has implemented it in its products. Google is kind enough to release the source, so others may follow. But still, this is concerning, that a non-standard protocol is being used to greatly improve a specific leveraging of website+client software. That isn't following the spirit of the web, as I see it.
Regarding standards, we're still experimenting (sorry that protocol changes take so long!).
Not to diminish your work or its importance in any way, but do you not see anything wrong with implementing this in production in Chrome and Google websites, long before there is a standard? I mean specifically the fact that it makes the combination of Chrome and Google websites perform much better together, than if you replace either with a competitor's product. Your browser competitors cannot compete with that, since they don't own powerful websites like you do. Your server-side competitors can't compete with that either, since they don't own a popular browser like Chrome (with the exception of Microsoft - if they did this, I would be just as concerned). Again, I have no problem with the work in general, or with experimenting with protocols. What I find concerning is doing this testing in production, and leveraging google.com and Chrome to help each other in ways others cannot easily duplicate.
Or perhaps I read TFA incorrectly. Is this actually enabled by default in production, in Chrome and google.com?
And unlike that other giant software company back in the old days, they don't have an overwhelming market share
Google's position in search is pretty overwhelming I'd say (except maybe in China). If Chrome is suddently twice as fast on Google websites then all other browsers, then gives the combination of Chrome+Google websites a huge advantage.
If they make it incompatible, then nobody will use it.
It is incompatible with all other websites and all other browsers - it only works with the combination of Chrome+Google's own websites.
If this were not open source, it would be totally evil. But is it fully open source right now, though, both client and server? There appears to be code out there, but it isn't clear to me how functional that is and how easy it would be to integrate in other browsers or other webservers.
So overall I have a very uneasy feeling about this. A non-standard extension is being pushed out, that makes the combination of Chrome+Google websites much faster. Google's control of Chrome and Google websites, and those website's dominant position on the web, makes it possible for Google to integrate the two in ways that none of their competitors can. If the source is functional and open, at least Google makes it possible for others to catch up... later.
This is not quite the ideal vision of a standards-based web, where anyone can write a new browser or a new webserver, and compete fairly on even ground.
I am not on the JS team myself, so I am not up to date on everything they are doing. But I have heard they are currently considering generational GC, after recently adding compartments. See this tracking bug and the links in it, for example.
The problem is that every time you change the major version number the UI usually changes and all add-ons have to be tested and updated.
I agree that this will be challenging for addon writers. Part of the solution is the Jetpack API, which is very stable, but not all addons can use it. So I completely understand your concerns here.
I am not on the addons team myself, but from what I understand they are trying hard to make this as easy as possible. And there really should not be many UI changes between FF4 and FF5, just like there are hardly any between Chrome X and X+1 - simply because not a lot of time passes between them.
The reason Google do it, and why we are now starting to do it too, is to get code into users hands faster. For example, we had WebM support last year, but only shipped it to users last week. (Beta users had it since last year, but not most of our users.) The same is true for JavaScript performance - we improve it all the time, so the quicker we get it into users' hands, the faster their browser is.
Why not just improve the code you have rather than writing new code?
We do both. Some people do mainly one or the other, others do a combination, like me. For example, I did a lot of work on improving performance, so that is improving existing code, and right now I am working on adding new functionality (IndexedDB in Fennec).
We'll basically end up saying something like IE 7-9 are supported, along with Firefox and Chrome versions no one in the world uses.
In reality, pretty much all browsers work, but sometimes there are small glitches the customers do not like. Those customers will just have to use internet explorer.
I think that what will happen is basically that IE and Safari will become the 'stable' browsers that big corporations standardize on, because they change infrequently, while Firefox and Chrome are the 'fast-moving' browsers that are faster, have more new features, etc.
What's the big deal? Frequent releases are good, it keeps crowd interest in your browser alive. It doesn't matter for me though, I use minefield which I presume will keep getting updated.
Yeah, minefield will continue to update every night.
What actual features and improvements could they possibly have added in "8 WEEKS" since the release that they have had time to actually put through an Alpha test, Beta test, and then full release that would warrant a VERSION 5!?!
This seems crazy lame to me. The browser has slowly gotten bloated, now the number? Why?
Hi there, I work on Firefox. First thing, we didn't write the article linked to in the summary, and I don't think they gave a totally accurate description. In fact, I don't even think this was interesting enough for a blog post from them.
We are basically going to switch to a development process that is very similar to Google's with Chrome. So everything you say here is valid about their development practices as well - rapidly rising version numbers for no reason, little features in 'major' releases, etc.
Why are we doing it? There is just one reason, it helps get code shipped faster. Code does not get written faster though, in either Chrome or the new Firefox process:) It just gets shipped quicker. But that is important too, and that's why we (and Google) are doing this.
Basically, Chrome and Firefox will release quickly, with small amounts of changes each time. I agree with you 100% that the major version number rising each time is silly! Personally I would either drop the version number entirely, or use something like Ubuntu's versioning scheme (10.10 for 10th month, 2010). But oh well.
In any case, since you asked what will ship in Firefox 5, I can tell you about stuff I know about (which is platform/backend stuff, not frontend). We have several improvements to performance that should be very useful, in both JavaScript and graphics. In particular WebGL should be faster on some cool demos on Linux, which I am very happy about.
I suspect the best way to find that out is to search for a blogpost about it, I remember there being one. Best I can find now is this, which is related.
Might be even faster to ask on mozilla's IRC (probably #developers or #planning) for directions to that information. Sorry I don't know more.
I do platform stuff myself, so I am not really involved in frontend changes and decisions (mainly since I am not that interested in it), so I can't properly answer that, sorry.
I'd really like to know where these ideas come from, and what the vetting/decision process is.
Well, first of all, these are just ideas someone had - the article isn't reporting on concrete plans for anything. It is very possible these features will not be decided upon, and something else will be.
Second, I do platform stuff and not frontend, but basically discussions are done in IRC, and in publicly open meetings (like this), where anyone can dial in and listen or interact. Eventually decisions are made, however like many open source projects, often code decides in the end (if no one writes code for a feature, it dies, and vice versa).
The backend work done for FF4 is good and much appreciated, but the it sounds like the team is resting on its laurels again: it thinks the work on the basics is done. Standards support is still not where it needs to be, yet they're working on fluff like site-specific browsers. It sounds like it's time for someone to go back to the basics again: just a browser in the core, with a good extension model for people to hack all these things into for people who actually want them.
Hi there, I'm a Firefox dev. I'd like to point out that we are not resting on anything;) There are people working on frontend stuff like this article reported on, and there are people (like me) who work on platform/backend stuff. These are different people, so if some people are working on app tabs etc., that doesn't mean that they are working on that instead of platform stuff. Both stuff is being worked on, but for some reason frontend gets more press;)
Just a few examples of things we are working on in the platform: A Type Inference engine for JavaScript to make it even faster; a new graphics library; a split-process model (this already shipped in mobile Firefox, should ship in desktop late this year), support for lots of new HTML5 features (on both desktop and mobile), improvements to JavaScript garbage collection, and of course lots of other improvements big and small.
My main issue with Firefox right now is not a lack of Facebook integration (-_-) but the obvious memory leakage in the released FF 4 with AdBlock/NoScript, which was present through the entire last half of the beta cycle.
Hi, I'm a Firefox dev. We are constantly working hard on memory issues, you can follow this meta-bug for example, to see how progress is going.
The fact is though, that the people that work on frontend stuff like app tabs and so forth, are different from the people that work on more hardcore things like memory usage. It isn't as if we can say, everyone should work on memory usage now. So we will always have a lot of work going on on both frontend and platform stuff - but, by the nature of things, the press and blogs will report on frontend stuff. So you might get the idea that Firefox devs are all working on things like app tabs and panorama - but that is very untrue! It's just that platform improvements under the hood are, well, under the hood;)
Btw, a long-term solution for all these memory issues will likely be when we switch to one process per tab. Then we'll have something similar to what Chrome has - higher baseline memory usage (overhead of processes and duplication, etc.), but more predictable memory freeing when tabs are closed and a very easy way to see which tabs are responsible for which memory. We are already working very hard on this, and a version of it shipped with Firefox Mobile just now, actually (separate processes for the UI and for web content) - so while it's not done yet, it's making very good progress. A release of desktop Firefox late this year should add the same functionality.
They also don't account for the battery saved in FF/Chrome by blocking intrusive graphical ads and their related javascript/flash.
Yes, this is huge. AdBlock/FlashBlock can save a lot of power.
They also don't test real-world Javascript-heavy web apps like Gmail
Very true. I'd expect the browsers with the fastest JS engines, Chrome and Firefox, to be better there, since faster JS engines means scripts complete faster, and the CPU is used for less time.
Slashdot Mirror
AdBlock and Firebug are both know to cause memory problems in some cases. I believe this will, at least in part, be fixed in Firefox 4.0.1 - which was launched the other day I think (maybe you already updated to it). But even so, they are good first suspects. Firefox lets addons modify a lot of internal things, which makes useful addons like AdBlock and Firebug possible, but also gives them the opportunity to (easily) create memory leaks.
In general, though, my best suggestion would be to see how things are without *any* plugins or addons. Simplest way is to create a new profile, and disable plugins and addons in it. Then browse for a while and see how things are. Odds are, you won't see strange memory behavior, and then the question is, which addon or plugin it is, and you can reenable them one by one til you find the guilty one.
Long-term, most addons will probably become Jetpack addons, which is a model similar to Chrome's. That kind of addon is more limited in what it can do, but also unable to cause memory leaks. Aside from that, we are moving to a one process per tab model, also like Chrome, will will help narrow down which page is responsible for large amounts of memory being used, when that happens. In the short term, though, problems like yours are almost always caused by addons or plugins, and I apologize for the hassle, the best thing to do is to find which it is, as I said earlier.
If you prefer to change that behavior, it's easy to do - change browser.sessionhistory.max_total_viewers in about:config to 0. Then it won't cache pages. You will have slower loading of pages when you press back, restore recently closed tabs, etc., but if you would rather save that memory then that's cool.
In my personal experience, and also in surveys of Firefox users, the caching is almost always a good thing - it does not lead to any system slowdown, and does speed up the responsiveness of the browser. But that doesn't mean it's what everyone wants, and maybe your browsing habits are in a way that caching isn't a good idea - so the caching is configurable.
That sounds normal to me - going from 178MB to 223MB isn't unexpected. You probably have several pages cached, each taking a few MB. That, and things like the JS heap 'settle' on a slightly higher amount of RAM soon after load (and stay there), as they keep allocated pages held to not waste time reallocating them later. There is also some effect of memory fragmentation (which makes more memory appear to be allocated than has been).
An interesting comparison would be, to load those exact pages in Firefox and a few other browsers. They will probably show similar memory behavior, but if they don't, please let me know!
Thanks for the valuable feedback to the OP. Comments like this keep me coming back to Slashdot.
Out of curiosity, is there an option to turn on aggressive releasing of pages? It seems to me to be a good idea, but without being familiar (even remotely) with the source code and design perhaps there are reasons against this (if there is indeed no option to turn it on/off).
Cheers
You can simply tell Firefox to not cache anything by setting browser.sessionhistory.max_total_viewers to 0 in about:config. Then once you browse away from a page, it's memory will all be released. More details here
The problem with this is that pressing 'back' will mean a complete reload of the page you just left. At least in my experience, caching pages is almost always worth it (unless you have machine with very limited RAM).
Does that mean they weren't using a profiler before now?? That... actually explains quite a bit...
No, we use profilers ;) In fact we have some valgrind - the awesome Linux profiling tool - devs working here.
Profile guided optimization is something else though. It is a special way of compiling and linking, that the compiler and linker use profiling information to know how best to optimize the code. So code that is used a lot is compiled with -O3 (the most optimizations), while code that is not used a lot gets -Os (to take less space), and so forth. This is a very useful technique that was not available on Linux until last year, and the news today is that Firefox now builds properly with it and there is a nice noticeable speed improvement for Linux users.
Install FF 4, browse a while, close all but one _blank_ tab and guess what? Firefox uses 7-800 MB _active_ memory.
Hi, I'm a Firefox dev. That sounds very bad. Can you please give some more details about how to reproduce it: Are you using a new profile? Are there any addons and plugins installed? What websites do you visit? And what specific Linux distro are you on?
Note that this might not be a bug: For example, if you visit a website that shows 200MB of images, then close that tab, then the memory is not necessarily freed. The reason is that the page stays cached, so that if you do 'History->Recently closed tabs' and open it, it will appear quickly. On a machine with lots of memory (most these days), that behavior tends to work better than releasing pages aggressively. However, if you aren't visiting websites with extreme memory use like that, then this might be an actual bug.
Getting back to your problem: With a new profile and no addons or plugins, we are unaware of a bug that causes anything like that. So I would be very grateful to you if you can point us to a bug we don't know about, so that we can fix it. If you give me steps that I can use to reproduce the problem (on my Linux machine over here),then you have my promise that I will l personally look into this and do everything in my power to fix it.
Though, maybe their way of doing it or updates in makefiles help maintainers of distributions to put better builds. I guess that's what matters, not their own build on web page.
Exactly, yeah. Most Linux users probably get Firefox through their distro, but the effort and patches that got this improvement done, will allow distros to compile in the same way and get the same speedup. If everything goes right, distros should be able to compile with these options and things will just work.
However according to Hommey, these new faster and less sluggish builds of Firefox for Linux will be available only from Firefox 6 onwards and we expect the first beta of Firefox 6 to available only by September - October 2011.
Note that you do not need to wait, if you are ok with running a Nightly build. Nightly builds are the latest code, so they are obviously less stable. But you can get this improvement right now if you want it.
Otherwise, you can wait just a few weeks and Firefox 6 Aurora will be released, which is somewhat more stable, and will include this code. (6 weeks later will be a Beta, and 6 weeks after that, a stable release.)
The example doesn't work. Also even if it did it would be "marking the first such scripting language alternative to JavaScript" only for people who want to restrict their website to Chrome users.
Which is a shame, especially as it is totally avoidable: It is possible to compile Tcl to JavaScript (using Emscripten), which would allow you to script the web using Tcl on any web browser and on any platform.
Disclaimer: I wrote Emscripten, sorry to pimp my own project. But if you are a Tcl hacker and want to compile it to JavaScript, please get in touch, I'd love to help.
I don't mean that innovation is bad. I was careful to clarify that before. And I further clarified that I did not mean to diminish in any way his work.
It is still a valid concern, that a new nonstandard protocol is being used to optimize a specific combination of super-popular website plus popular client software, as it puts all competitors at a disadvantage. The purpose of standards is to level the playing field.
And the purpose of innovation is to move us forward. You can - and should - still innovate, just not in this way, of running a nonstandard protocol in production. You can, instead, run the nonstandard protocol in part of the production code, either randomly assigned or opt-in. I would have no problem with that. I realize this may seem like a small difference, but it really isn't.
That node.js implementation is from 3 days ago. It probably isn't ready for production.
Right now, Chrome+google.com is the only production combination that benefits from SPDY. Simply because Google developed SPDY and has implemented it in its products. Google is kind enough to release the source, so others may follow. But still, this is concerning, that a non-standard protocol is being used to greatly improve a specific leveraging of website+client software. That isn't following the spirit of the web, as I see it.
Regarding standards, we're still experimenting (sorry that protocol changes take so long!).
Not to diminish your work or its importance in any way, but do you not see anything wrong with implementing this in production in Chrome and Google websites, long before there is a standard? I mean specifically the fact that it makes the combination of Chrome and Google websites perform much better together, than if you replace either with a competitor's product. Your browser competitors cannot compete with that, since they don't own powerful websites like you do. Your server-side competitors can't compete with that either, since they don't own a popular browser like Chrome (with the exception of Microsoft - if they did this, I would be just as concerned). Again, I have no problem with the work in general, or with experimenting with protocols. What I find concerning is doing this testing in production, and leveraging google.com and Chrome to help each other in ways others cannot easily duplicate.
Or perhaps I read TFA incorrectly. Is this actually enabled by default in production, in Chrome and google.com?
And unlike that other giant software company back in the old days, they don't have an overwhelming market share
Google's position in search is pretty overwhelming I'd say (except maybe in China). If Chrome is suddently twice as fast on Google websites then all other browsers, then gives the combination of Chrome+Google websites a huge advantage.
If they make it incompatible, then nobody will use it.
It is incompatible with all other websites and all other browsers - it only works with the combination of Chrome+Google's own websites.
If this were not open source, it would be totally evil. But is it fully open source right now, though, both client and server? There appears to be code out there, but it isn't clear to me how functional that is and how easy it would be to integrate in other browsers or other webservers.
So overall I have a very uneasy feeling about this. A non-standard extension is being pushed out, that makes the combination of Chrome+Google websites much faster. Google's control of Chrome and Google websites, and those website's dominant position on the web, makes it possible for Google to integrate the two in ways that none of their competitors can. If the source is functional and open, at least Google makes it possible for others to catch up... later.
This is not quite the ideal vision of a standards-based web, where anyone can write a new browser or a new webserver, and compete fairly on even ground.
I am not on the JS team myself, so I am not up to date on everything they are doing. But I have heard they are currently considering generational GC, after recently adding compartments. See this tracking bug and the links in it, for example.
The problem is that every time you change the major version number the UI usually changes and all add-ons have to be tested and updated.
I agree that this will be challenging for addon writers. Part of the solution is the Jetpack API, which is very stable, but not all addons can use it. So I completely understand your concerns here. I am not on the addons team myself, but from what I understand they are trying hard to make this as easy as possible. And there really should not be many UI changes between FF4 and FF5, just like there are hardly any between Chrome X and X+1 - simply because not a lot of time passes between them.
What purpose does shipping code faster serve?
The reason Google do it, and why we are now starting to do it too, is to get code into users hands faster. For example, we had WebM support last year, but only shipped it to users last week. (Beta users had it since last year, but not most of our users.) The same is true for JavaScript performance - we improve it all the time, so the quicker we get it into users' hands, the faster their browser is.
Why not just improve the code you have rather than writing new code?
We do both. Some people do mainly one or the other, others do a combination, like me. For example, I did a lot of work on improving performance, so that is improving existing code, and right now I am working on adding new functionality (IndexedDB in Fennec).
We'll basically end up saying something like IE 7-9 are supported, along with Firefox and Chrome versions no one in the world uses. In reality, pretty much all browsers work, but sometimes there are small glitches the customers do not like. Those customers will just have to use internet explorer.
I think that what will happen is basically that IE and Safari will become the 'stable' browsers that big corporations standardize on, because they change infrequently, while Firefox and Chrome are the 'fast-moving' browsers that are faster, have more new features, etc.
What's the big deal? Frequent releases are good, it keeps crowd interest in your browser alive. It doesn't matter for me though, I use minefield which I presume will keep getting updated.
Yeah, minefield will continue to update every night.
What actual features and improvements could they possibly have added in "8 WEEKS" since the release that they have had time to actually put through an Alpha test, Beta test, and then full release that would warrant a VERSION 5!?! This seems crazy lame to me. The browser has slowly gotten bloated, now the number? Why?
Hi there, I work on Firefox. First thing, we didn't write the article linked to in the summary, and I don't think they gave a totally accurate description. In fact, I don't even think this was interesting enough for a blog post from them.
:) It just gets shipped quicker. But that is important too, and that's why we (and Google) are doing this.
We are basically going to switch to a development process that is very similar to Google's with Chrome. So everything you say here is valid about their development practices as well - rapidly rising version numbers for no reason, little features in 'major' releases, etc.
Why are we doing it? There is just one reason, it helps get code shipped faster. Code does not get written faster though, in either Chrome or the new Firefox process
Basically, Chrome and Firefox will release quickly, with small amounts of changes each time. I agree with you 100% that the major version number rising each time is silly! Personally I would either drop the version number entirely, or use something like Ubuntu's versioning scheme (10.10 for 10th month, 2010). But oh well.
In any case, since you asked what will ship in Firefox 5, I can tell you about stuff I know about (which is platform/backend stuff, not frontend). We have several improvements to performance that should be very useful, in both JavaScript and graphics. In particular WebGL should be faster on some cool demos on Linux, which I am very happy about.
I suspect the best way to find that out is to search for a blogpost about it, I remember there being one. Best I can find now is this, which is related.
Might be even faster to ask on mozilla's IRC (probably #developers or #planning) for directions to that information. Sorry I don't know more.
I do platform stuff myself, so I am not really involved in frontend changes and decisions (mainly since I am not that interested in it), so I can't properly answer that, sorry.
I'd really like to know where these ideas come from, and what the vetting/decision process is.
Well, first of all, these are just ideas someone had - the article isn't reporting on concrete plans for anything. It is very possible these features will not be decided upon, and something else will be.
Second, I do platform stuff and not frontend, but basically discussions are done in IRC, and in publicly open meetings (like this), where anyone can dial in and listen or interact. Eventually decisions are made, however like many open source projects, often code decides in the end (if no one writes code for a feature, it dies, and vice versa).
The backend work done for FF4 is good and much appreciated, but the it sounds like the team is resting on its laurels again: it thinks the work on the basics is done. Standards support is still not where it needs to be, yet they're working on fluff like site-specific browsers. It sounds like it's time for someone to go back to the basics again: just a browser in the core, with a good extension model for people to hack all these things into for people who actually want them.
Hi there, I'm a Firefox dev. I'd like to point out that we are not resting on anything ;) There are people working on frontend stuff like this article reported on, and there are people (like me) who work on platform/backend stuff. These are different people, so if some people are working on app tabs etc., that doesn't mean that they are working on that instead of platform stuff. Both stuff is being worked on, but for some reason frontend gets more press ;)
Just a few examples of things we are working on in the platform: A Type Inference engine for JavaScript to make it even faster; a new graphics library; a split-process model (this already shipped in mobile Firefox, should ship in desktop late this year), support for lots of new HTML5 features (on both desktop and mobile), improvements to JavaScript garbage collection, and of course lots of other improvements big and small.
My main issue with Firefox right now is not a lack of Facebook integration (-_-) but the obvious memory leakage in the released FF 4 with AdBlock/NoScript, which was present through the entire last half of the beta cycle.
Hi, I'm a Firefox dev. We are constantly working hard on memory issues, you can follow this meta-bug for example, to see how progress is going.
;)
The fact is though, that the people that work on frontend stuff like app tabs and so forth, are different from the people that work on more hardcore things like memory usage. It isn't as if we can say, everyone should work on memory usage now. So we will always have a lot of work going on on both frontend and platform stuff - but, by the nature of things, the press and blogs will report on frontend stuff. So you might get the idea that Firefox devs are all working on things like app tabs and panorama - but that is very untrue! It's just that platform improvements under the hood are, well, under the hood
Btw, a long-term solution for all these memory issues will likely be when we switch to one process per tab. Then we'll have something similar to what Chrome has - higher baseline memory usage (overhead of processes and duplication, etc.), but more predictable memory freeing when tabs are closed and a very easy way to see which tabs are responsible for which memory. We are already working very hard on this, and a version of it shipped with Firefox Mobile just now, actually (separate processes for the UI and for web content) - so while it's not done yet, it's making very good progress. A release of desktop Firefox late this year should add the same functionality.
They also don't account for the battery saved in FF/Chrome by blocking intrusive graphical ads and their related javascript/flash.
Yes, this is huge. AdBlock/FlashBlock can save a lot of power.
They also don't test real-world Javascript-heavy web apps like Gmail
Very true. I'd expect the browsers with the fastest JS engines, Chrome and Firefox, to be better there, since faster JS engines means scripts complete faster, and the CPU is used for less time.