The Firefox teams seems to no longer care about add-ons and add-on users. I am an Add-on author. I submitted an updated version of my addon for Firefox 8 on October 27. Twelve days later the new version is still sitting in a sandbox waiting editorial review. With a new release happening every 6 weeks this kind of behavior is inexcusable and will likely drive people away from Add-ons.
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?
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.
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.
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.
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'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.
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.
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.
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 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.
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.
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)
The Sync API is documented, and Mozilla encourages development of outside server and client implementations. Sync is available for tablets and smartphones.
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.
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.
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.
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.
Mozilla will soon be auto-updating Firefox every 6 weeks like Chrome, so half the Internet will be getting a regular update and progress will happen much more quickly. The version number is irrelevant. Personally, I think it's amazing that we can move this quickly.
Considering the whole reason they're doing this crap is to make it look like they're keeping up to date with Chrome, yeah, it kinda does make a difference.
Methinks they don't understand the concept of "Major release.minor release"
The reason they are doing this is to get updates out to users faster not slower.
Look at the memory changes from 4->8, they're putting in updates little by little. The train station model of development fits web browsers much better than prolonged giant version leaps that change almost everything.
That's not why they are doing it. It's because it's better for everyone if things like browsers are essentially versionless, and everyone is on the newest version. Immediate automatic updates mean that users are always able to access the newest features.
That's an awfully subjective position to take. I don't have a problem with rapid release, but I have a problem with passing off minor revisions and bugfixes as major releases.
And try to tell me the version doesn't matter when there's a regression or otherwise something broken on a newer rev that works fine on an older one.
I don't know where this recent trend of "version numbers are evil" came from, but it's entirely silly.
Is it really silly? Gmail doesn't have version numbers. Facebook doesn't have version numbers. Hacker News doesn't have version numbers. Twitter doesn't have version numbers. They may refer to "the new version" or "the new, beta version" but not by number.
On the dev side, you might refer to a particular code snapshot with a "version number" that might as well be 3.2 or r304 or "2011-08-3 12:03:47" or d1b119d8f117b16fcfa58b2be60df87a6c45ac58. Considering the nightmares caused by conservative IT groups enforcing version X of software Y for years, eliminating version numbers from the public for something as critical as a browser seems like a good move to me on security alone. For other things the formal major.minor.release-revision can still make sense. Personally I miss the "even minor version represents stable, odd unstable" pattern that's increasingly fallen out of use.
>Is it really silly? Gmail doesn't have version numbers. Facebook doesn't have version numbers. Hacker News doesn't have version numbers. Twitter doesn't have version numbers.
Web apps and installed programs are completely different animals.
Actually, they understand it quite well; fixes to released versions of Firefox use dotted version numbers like that. Mozilla just switched from doing major releases on a timescale of 1-2 years to doing major releases many times per year.
Among other things, that has improved the quality of the browser, since features don't have to rush to meet the release deadline when they can just wait for the next one right around the corner.
But nothing has really changed, except what they refer to each release as.
I've always been a fan of this definition:
A minor release contains bugs fixes and minor feature changes (For example, 1.0 to 1.1). Major releases include major functionality and feature enhancements (e.g. 1.x to 2.0).
The problem comes in that they're releasing minor bugfixes and patches as major releases, for no other reason than to compete on the numbers system.
I don't think the answer is "abolish the numbers", I think the answer is "be honest".
You were off by a bit there. We should expect to be on version 16 by this time next year. Not that the version number should be important to end users. Just developers.
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...
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.
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.
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.
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.
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).
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 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.
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.
https://addons.mozilla.org/en-US/firefox/addon/categorize/