Firefox 8.0 is Released(mozilla.org)
mozilla.org
Firefox 8.0 is Released
https://www.mozilla.org/en-US/firefox/8.0/releasenotes/
78 comments
Known problem with the compatibility system, and Mozilla plans to address it in the near future by improving the notion of compatibility, as well as adding the ability to quickly mark an existing version of an addon as compatible when it doesn't need changes.
I disagree. The folks at Mozilla are not so quietly encouraging developers to get involved in the alpha and beta releases to ensure that things do work on day one of a release? How much work was done up to October 27 ensuring that your add-on was ready to go?
Sorry Sanddancer but my experience as an add-on author is that writing free add-ons can quickly turn to a demanding job.
For example, if you look at the tab mix plus add-on source code you can find a very long list of workarounds to make it work in different contexts.
For example, if you look at the tab mix plus add-on source code you can find a very long list of workarounds to make it work in different contexts.
My last addon release was reviewed after a little over a month.
They do however do automatic check to ensure that your addon still works with newer releases and upgrade the compatibility automatically.
They do however do automatic check to ensure that your addon still works with newer releases and upgrade the compatibility automatically.
The add-on thing could be huge, if it works out. I am tired of seeing computers riddled with spybars.
Yep - I was very impressed to see the update installer ask if I want to keep add-ons installed by a third party, with the default option being no.
Definitely a good idea for Windows users, and possibly Macs as well (I don't know the prevalence of browser-infesting software there).
On Linux, though, it promptly flagged all of the addons I had installed through the distro packaging system as "third-party addons" and wanted to disable them by default.
On Linux, though, it promptly flagged all of the addons I had installed through the distro packaging system as "third-party addons" and wanted to disable them by default.
so it worked properly on Linux.
there is no way to know whether an addon instaled 'for the whole' system was added by third party, or by package. only addons in Your home dir are considered as 'installed by you'
Except that Linux doesn't tend to suffer from the browser-infesting stealth installs common to other platforms; the case of packaged addons seems far more common and likely.
ubuntu?
yes, you can unistall it, but popular distros do come with pre-installed stuff.
Folks at mozilla - keep up the good work. Could you create some videos and tutorials about extension development?
Tutorials (and learning material in general) can be found on https://developer.mozilla.org/en/Extensions. This page seem to cover both API (XUL & Jetpack).
I am aware of the page and have written an Extension in the past. I am unclear about the following things
a) Is Jetpack the way to go going forward? How much of the XPCom api is available through Jetpack?
b) Is there an IDE I can setup that will allow me to get autocompletion for extension development?
c) Is there an API browser for XPCom objects listing the objects, the methods available on them and the minimum version of Firefox that supports the particular api? Having a searchable index would be even better.
d) When I was working on a Firefox extension I often got the feeling that I was doing something suboptimal because the development process seemed pretty broken. I was building extensions and had to restart the browser for them to take effect, getting a debugger going was more work than it should be, I wondered why isnt the Firefox ui itself written using HTML and css. I am hoping that more tutorials and workflow related posts will address many of my concerns.
Knowing the workflow of folks at mozilla will be a huge help to people like me who are working on writing extensions because the road to writing a meaningful extension is not as straightforward as it could be.
In the end I dont want the above points to act as a downer in a software release post and would like to congratulate folks at Mozilla about the great work that they do.
Knowing the workflow of folks at mozilla will be a huge help to people like me who are working on writing extensions because the road to writing a meaningful extension is not as straightforward as it could be.
In the end I dont want the above points to act as a downer in a software release post and would like to congratulate folks at Mozilla about the great work that they do.
Jetpack is preferred because it's easier to write, reduces compatibility problems between versions (because there are fewer "hooks" into deep FF innards), and you don't have to restart to install, uninstall, or reload them. Of course there are limitations, but unless you really need something in XUL that's not available in Jetpack, Jetpack is the way to go.
Have the memory issues been resolved? Under Windows 7, it isn't uncommon to find an idle Firefox browser with a few low-activity tabs using up more than 1.5GB of memory. It's gotten to a stage where I have to restart the browser every couple of days...reminds me of when I had to this with my Windows PC! I've recently moved over the Chrome and while I miss Firefox, the browser is far less of a memory hog.
Why does it bother you that an application is using so much RAM? Do you only have 2 GB or something like that? I'd prefer that applications used my RAM since unused RAM is just wasted electricity.
I find it strange that people still think of RAM as a precious resource that needs to be conserved and under-utilised. I'd rather have it used than have to fetch something from disk or the network.
I find it strange that people still think of RAM as a precious resource that needs to be conserved and under-utilised. I'd rather have it used than have to fetch something from disk or the network.
> I'd prefer that applications used my RAM since unused RAM is just wasted electricity.
I... but... er...
This is probably the most ridiculous thing I've ever seen on this site.
You could write a two line C program that allocates all the memory on your system and then sits in a loop doing nothing, but then you'd be wasting even more electricity because your hdd would be reading/writing to your swap space. :|
> I'd rather have it used than have to fetch something from disk or the network.
Modern operating systems do use your free memory for cache. Linux will regularly chill at 90%+ memory usage (the majority being cache that can be freed instantly when other apps need it) and Windows has SuperFetch which does basically the same thing as I understand.
I... but... er...
This is probably the most ridiculous thing I've ever seen on this site.
You could write a two line C program that allocates all the memory on your system and then sits in a loop doing nothing, but then you'd be wasting even more electricity because your hdd would be reading/writing to your swap space. :|
> I'd rather have it used than have to fetch something from disk or the network.
Modern operating systems do use your free memory for cache. Linux will regularly chill at 90%+ memory usage (the majority being cache that can be freed instantly when other apps need it) and Windows has SuperFetch which does basically the same thing as I understand.
Yes, you could write such a program.
Yes modern OSes do use non-Application RAM for caching, mostly files and other small buffers. While Firefox is probably doing a lot of caching for web content, something that modern OSes don't yet do. Hence I have no qualms about it using over a gig of RAM.
I guess my comment was read more angrily than I meant it to sound. What I mean is let applications use as much RAM as they need and be done with it.
Yes modern OSes do use non-Application RAM for caching, mostly files and other small buffers. While Firefox is probably doing a lot of caching for web content, something that modern OSes don't yet do. Hence I have no qualms about it using over a gig of RAM.
I guess my comment was read more angrily than I meant it to sound. What I mean is let applications use as much RAM as they need and be done with it.
Some of us actually use our RAM for other things...
If I have 6GB of RAM and feel like e.g. editing a bunch of very large photos or videos without closing my browser, it's annoying to have that browser using 25% of RAM.
Is it actually using 25% of physical RAM, or just (25% of 6GB) of Virtual Address space (well actually 4GB address space for 32 bit applications/browsers).
Then again do you actually notice a slow down when you try to edit those photos? Have you run benchmarks to see if it's really a problem with RAM usage or if it's some Flash or other plugin that's gobbling up your CPU, hence the slow down.
Does that really matter so much, since if you actually need to use that Physical ram for your editing task the OS should page out physical memory from the browser and other unused applications and make it available for your needs.
Then again do you actually notice a slow down when you try to edit those photos? Have you run benchmarks to see if it's really a problem with RAM usage or if it's some Flash or other plugin that's gobbling up your CPU, hence the slow down.
Does that really matter so much, since if you actually need to use that Physical ram for your editing task the OS should page out physical memory from the browser and other unused applications and make it available for your needs.
It was a hypothetical scenario based on a combination of past experiences. Right now Firefox shows 464M resident (RES column in top) with five tabs open (wait, it's growing, now it's 480M, 486...). After a couple of hours it will be close to 1GB resident.
I've been working on large images in Gimp and Hugin/panotools in the past, and reached a point where swap was being used. The system immediately slowed to an unusable crawl with only a few % of swap in use. Considering that rotating hard drives have a random access throughput of a few MB/s, it's not surprising. These days a swap partition's only use is hibernating. Swap is effectively useless.
One webapp I'm working on triggered a bug in older versions of Chrome that caused it to grow rapidly in size, quickly consuming all of memory. Fortunately that was fixed.
So basically, I'd like to have another GB of image data in RAM before hitting swap (or whatever it is I'm working on), while still having my browser responsive.
I've been working on large images in Gimp and Hugin/panotools in the past, and reached a point where swap was being used. The system immediately slowed to an unusable crawl with only a few % of swap in use. Considering that rotating hard drives have a random access throughput of a few MB/s, it's not surprising. These days a swap partition's only use is hibernating. Swap is effectively useless.
One webapp I'm working on triggered a bug in older versions of Chrome that caused it to grow rapidly in size, quickly consuming all of memory. Fortunately that was fixed.
So basically, I'd like to have another GB of image data in RAM before hitting swap (or whatever it is I'm working on), while still having my browser responsive.
I've had Firefox (versions 3 onwards) running for weeks at a time and only ever had it using between 400-500MB of RAM.
Another thing to check would be what kind of ad ons you had installed, since I would imagine that they could have quite a significant impact on memory usage and performance.
Another thing to check would be what kind of ad ons you had installed, since I would imagine that they could have quite a significant impact on memory usage and performance.
Is this great news, or good news, or nothing too exciting? Dunno. It might be interesting to learn how many people read this in another browser, popped over to firefox to update it ... and then returned to their other browser. We may be at the point where browsers are like toilet paper -- lots of brands will do the work, and it's hard to pay much attention to which one is installed.
Firefox Sync sort of changes that for me. It gives enough convenience that I've also gone Firefox on my mobile devices. Being able to access open tabs from my laptop on the phone is great when I'm sitting in the bus.
I really hope the persistent sync bugs get worked out soon. I'm told that the final, and big, fix was in alpha, which makes me think that it's not in 8.0. Soon, soon.
[deleted]
s/is released/has been released/;
Just got the notification, but didn't upgrade because a lot of my very useful extensions for HTML dev weren't compatible.
I don't think the new features in 7->8 make up for the lack of my extensions.
I don't think the new features in 7->8 make up for the lack of my extensions.
Use this extension to "make" your extensions compatible https://addons.mozilla.org/en-US/firefox/addon/add-on-compat...
This is great, thanks for posting it. I manage my passwords with 1Password, and while they're good about pushing updates, I've never seen their Firefox extension marked as compatible when a new version of Firefox is released.
1Password 3.8.7 seems to be compatible with Firefox 8 though. They're getting a lot better at keeping up with Firefox version lately (ever since they introduced Aurora and "maybe" Nightly support)
Why 1Password rather than Firefox Sync?
Which would beg the question why would I need an addon to make my current addons compatible with Firefox? Everyone knew that 6 weeks release cycle is going to break addons but they've decided to go with it anyway. I'd expect from Mozilla to make such decision after fixing the potential problems. I've been hearing this will be fixed soon but that date is yet to come.
As of Firefox 4.0, there is an extension api that is both version-less and allows restarting extensions without restarting the browser. Especially with Firefox's new release schedule, more extension developers should probably make the effort to start using it.
https://developer.mozilla.org/en/Extensions/Bootstrapped_ext...
https://developer.mozilla.org/en/Extensions/Bootstrapped_ext...
Unfortunately, there is little documentation. I have looked into adding this for my extensions, and didn't manage to do it. Same documentation issues I had when I first started to port my extensions for Firefox to Fennec: pieces of documentations here and there, but nothing that clearly explains the differences between the 2 platforms.
That said, their extension framework is by far the most powerful of all browsers.
That said, their extension framework is by far the most powerful of all browsers.
I disabled addon compatibility checking, and jumped from 7 to nightly (version 10) and was surprised to find all of my extensions still work great (including Firebug).
Mozilla is working towards making this happen automatically, but it seems to be working well already.
Mozilla is working towards making this happen automatically, but it seems to be working well already.
I just saw this being discussed today.. watch out for it if you have Firebug installed. There could be a performance regression because debugging is on even if you're not using it.
https://bugzilla.mozilla.org/show_bug.cgi?id=699528
https://bugzilla.mozilla.org/show_bug.cgi?id=699528
In 5 weeks they are going to be shipping Firefox 13.0.
[deleted](3)
It would make more sense (to me) that they focused on fixing some of the many bugs filed in the bug tracker. Just saying, but then Chrome is my browser of choice anyway...
You do realize that there were tons of bugs fixed between 7 and 8, right?
It's just that bugfixes never make the news.
It's just that bugfixes never make the news.
Chrome has over 31,000 open issues. http://code.google.com/p/chromium/issues/list
Dear Mozilla. Why do you keep doing all these full version releases? Seriously it's just annoying.
Just because IE is on version 10. Doesn't mean you have to be.
Why are you doing this....
You've gone from 3-8 in a year. That's not right.
"Full" version releases? There will be a new release every six weeks. Whatever features are ready to be shipped at that time will be released. There was a discussion about removing the version number from the "About" box but it was left in for debugging purposes. That's all the version number is for now. Since there are no "long-term support" versions, just make sure you're up-to-date and don't give the version number any mind.
> There will be a new release every six weeks.
The corrollary to this being that releases are no longer news.
The corrollary to this being that releases are no longer news.
Firefox and Chrome both have the same update cycle - a new major version every 6 weeks.
I believe the main reason for both projects doing it are allowing them to get improvements and new features to users faster. One or two releases a year means a very long time before improvements get to users, and it holds everything back. 6-week releases means you get improvements to users in just a few months.
Of course there are downsides to 6-week releases. If you prefer a slower-updating browser, there are other good options, such as Opera. And if you want even more stability, there are Safari and IE, which these days are quite good as well.
I believe the main reason for both projects doing it are allowing them to get improvements and new features to users faster. One or two releases a year means a very long time before improvements get to users, and it holds everything back. 6-week releases means you get improvements to users in just a few months.
Of course there are downsides to 6-week releases. If you prefer a slower-updating browser, there are other good options, such as Opera. And if you want even more stability, there are Safari and IE, which these days are quite good as well.
Although I've not looked into exactly why Mozilla have adopted the rapid-release cycle, I'd imagine it may be something to do with the ability to quickly drop backwards-compatibility and support. That way the code base can mature faster and less time is spent on redunant versions.
The most important reason for it was to keep new features from being stuck in limbo just because they happened to be part of the same branch as a feature that was taking a long time to be production ready. This is what killed us with 4.0. There were big and nice features in 4 that were actually ready more than 6 months prior to release, but they couldn't go because they were "full release" features and they were waiting for other features that were considered to be "must have" for 4.0.
With the rapid release cycle, when features start development, they have the ability to be easily configured out of the release product if they aren't ready for a particular version. We have a reliable release schedule that we expect to hit every 6 weeks. Obviously, we do our best to have as many new features as are ready be part of each release, but we don't leave people wondering when it will finally happen because we keep to the schedule and release the features that are ready.
Some of the biggest parts of this release were actually groundwork improvements to make the add-ons ecosphere more comfortable in the context of rapid release.
With the rapid release cycle, when features start development, they have the ability to be easily configured out of the release product if they aren't ready for a particular version. We have a reliable release schedule that we expect to hit every 6 weeks. Obviously, we do our best to have as many new features as are ready be part of each release, but we don't leave people wondering when it will finally happen because we keep to the schedule and release the features that are ready.
Some of the biggest parts of this release were actually groundwork improvements to make the add-ons ecosphere more comfortable in the context of rapid release.
I sort of understand their reasoning. It's easier to get people interested in a "full" release, than some 3.0.21 version every three mongths.
It also was more wrong to stay on 3.6.* for over two years.
A middle road might be to start a year with a full release and then do point-releases doing that year, so in 2013 we would have, for instance: 13, 13.0.1, 13.1, 13.2, 13.2.1, 13.3.
It also was more wrong to stay on 3.6.* for over two years.
A middle road might be to start a year with a full release and then do point-releases doing that year, so in 2013 we would have, for instance: 13, 13.0.1, 13.1, 13.2, 13.2.1, 13.3.
Mozilla is dropping the idea that some features are point releases and others are major version numbers. As a web browser there's always only been one web, so if a feature is ready then it's ready and it doesn't matter. Internally there's an actual product that other people might interact with -- and Firefox more than other browsers at that, as the traditional way to extend Firefox is to monkeypatch your changes in. But it was never quite so clear what a point release was there either, and it was getting in the way of advancing the core product.
I think simple dated releases would be an improvement (e.g., Firefox 2011.1, 2011.2, etc., or tag them based on month, this one being 2011.10, or 2011v2 or whatever.) But that's basically just a PR move. There's no longer anything really like a point release except in the case of regressions that demand an immediate fix (as happened with Firefox 7).
I think simple dated releases would be an improvement (e.g., Firefox 2011.1, 2011.2, etc., or tag them based on month, this one being 2011.10, or 2011v2 or whatever.) But that's basically just a PR move. There's no longer anything really like a point release except in the case of regressions that demand an immediate fix (as happened with Firefox 7).
This is a valid, on topic, cogent post. Why is it getting downvoted?
Perhaps because this argument has croppped up, like clockwork, with every release since FF5. It's boring, predictable, and doesn't add anything to the discussion.
Because version numbers are irrelevant, what's important is keeping people on the newest version. "Solving" the problem of large version numbers is like solving the problem 1/0.
At work we have a web application purchased about 18 months ago that officially don't support Firefox above 3.6. There were rendering differences between 3.6 and 4 that were serious enough to enforce that restriction for certain users. Apparently, it has begun working as expected again in FF7 (might have worked in FF6, not sure).
The application also uses jQuery 1.2.6 (released May '08) - I guess I'll be the one to QA the migration to the present day.
Hence I am not yet a believer in "latest version is the greatest version", in all cases. In principle, yes, but there are exceptions that makes version numbers necessary.
The application also uses jQuery 1.2.6 (released May '08) - I guess I'll be the one to QA the migration to the present day.
Hence I am not yet a believer in "latest version is the greatest version", in all cases. In principle, yes, but there are exceptions that makes version numbers necessary.
Let's be clear.
"The version number is too high" is one complaint.
"I have compatibility issues across releases" is another. They are not the same. They are not interchangeable.
What happened here perfectly exemplifies what happens every time a release is brought up. One of these complaints is brought up, then in the next breath it's switched to the other, as if we're still discussing the same thing.
We are not.
Conflating the two by bouncing between them multiple times in a discussion, every time the discussion occurs results in massive, unproductive churn.
"The version number is too high" is one complaint.
"I have compatibility issues across releases" is another. They are not the same. They are not interchangeable.
What happened here perfectly exemplifies what happens every time a release is brought up. One of these complaints is brought up, then in the next breath it's switched to the other, as if we're still discussing the same thing.
We are not.
Conflating the two by bouncing between them multiple times in a discussion, every time the discussion occurs results in massive, unproductive churn.
I'm not entirely sure, but I think Mozilla will continue to support Fx 3.6 until they have a better solution for large companies. I'm not sure what that better solution would be, but I believe they're trying to solve the problem.
Here is a post about where Chrome and Firefox are probably heading http://www.codinghorror.com/blog/2011/05/the-infinite-versio....
The biggest problem with updates are regressions. Since Firefox uses four release channels (since the introduction of the Aurora channel), most features get a decent amount of testing before being introduced to stable.
The biggest problem with updates are regressions. Since Firefox uses four release channels (since the introduction of the Aurora channel), most features get a decent amount of testing before being introduced to stable.
the whole point of this scheme is that there shouldn't be point releases. having them throughout the year is just as bad as any other point release.
the reason behind going to full numbers is that if you don't have the latest version, you have the wrong version. if there is a 13.1 and a 13.2, it makes it seem like people using 13.1 are still using the latest version. they aren't.
the reason behind going to full numbers is that if you don't have the latest version, you have the wrong version. if there is a 13.1 and a 13.2, it makes it seem like people using 13.1 are still using the latest version. they aren't.
https://addons.mozilla.org/en-US/firefox/addon/categorize/