Avoiding breaking extensions
Some Firefox users (I don't know how many) refuse to upgrade to new major versions because their favorite extensions break. Users who don't upgrade miss out on new features, new extensions, and security fixes. What can be done to reduce the number of extensions that break when a new version of Firefox is released? Some ideas:
- Make sure extension authors know when all the major changes for a release have happened, so they have plenty of time to test their extension against the trunk/alpha/beta and bump maxVersion. Ensuring that all major changes for Firefox 1.1 happen before Firefox 1.1 beta might be a good way to accomplish this.
- Ensure that mozilla.org has permission to distribute new versions of extensions listed on UMO that authors abandon.
- Make maxVersion optional (bug 251148).
- Let users override a specific extension's maxVersion through the Extension Manager UI.
- Broken XUL overlays should not break XUL windows with XML errors. Instead, they should disable the extension or make the overlay be ignored.
- Try to freeze interfaces that extensions use.
May 4th, 2005 at 3:35 am
Wasn’t “freeze interfaces that extensions use” one of the big things about 1.0? If 1.1 breaks a lot of extensions, people will get quite angry, I imagine.
May 4th, 2005 at 3:50 am
Personally, I am one of those users who has at some time stopped upgrading. This was mainly before 1.0 – the easier ability to update an extension muted my reluctance a bit. I think the most important thing on that list is let users override a specific extension’s maxVersion through the Extension Manager UI.
It is inevitable that extension interfaces change because the firefox interface is so entwined with the extensions – the interface is not a black box, but extensions rip into the internals of firefox. And not setting a maxVersion just means people will be in unsupported territory.
May 4th, 2005 at 4:04 am
Jesse, you haven’t seen any user support requests for quite some time, it seems.
Firefox users are just not capable of handling broken extensions. Thus, someone has to do it. That’s what maxVersion is good for. (Yeah, one may pref it, if it really has to be, like for nightlies.)
Regarding the redistribution of extensions, I guess that most of the extensions on umo are actually open source, so there is no problem with that at all. Just that nobody has the money to pay for the manpower to do so. If a community wants an extension, it will find resources to get it. Mozilla.org will not.
Regarding the “let developers know”, that’s one of those myths that everybody talks about. Yeah, docs are cute and all, and “we” definitly try to improve here (read devmo), but there is no way to get that perfect. On the other hand, with all the locales needing freezes and QA and release candidates, extension authors probably have a week or two to at least test their extensions before a final ships (that is a stable build, not a preview).
Regarding the breaking of APIs, that’s what you get for fixing bugs. You can’t fix a bug without changing the prior behaviour of code, and sometimes it involves fixing an API. That’s life, if an extension developer has to use unfrozen interfaces, she should know what she’s dealing with.
May 4th, 2005 at 8:07 am
Greasemonkey has been broken by 1.0.1, 1.0.2, 1.0.3, and soon by 1.0.4.
I don’t think we’re much of an exception, except that we’re active enough to be fixing it.
Chrome’s prompt function was broken in 1.0.1(!).
May 4th, 2005 at 11:29 am
As an extension author I must say it’s extremely annoying to need to update the extension every once in a (short) while just to up it’s max-version (yes, i know iI can only update the update.rdf file).
It’s the responsibility of the platform to try and stay as backward compatible as possible. Not every developer has time to update, and deserted extensions may disappear, while they would stay perfectly functional if their max-version was higher. Imagine every developer of a DOS application had to update his application with every new minor version of DOS. This is just unimaginable.
Of course, some extensions may not work with newer versions, and the user should be able to know if that MIGHT happen, but let the user choose.
The max-version thingy is an embedded drawback of the current system, and simpliy put, plain PITA.
avih
May 4th, 2005 at 12:19 pm
No, maxVersion should not be optional. There were quite a few bug reports already about the broken in 1.0.3 Dictionary Search extension, imagine what happens if someone decides his extension is compatible with all further Firefox versions. There are no extensions that only use frozen interfaces, just because XUL isn’t frozen (remember the changes in 1.8?)
Yes, maxVersion a PITA for extension authors, but it’s much better than making Firefox user base (grandpa & grandma, you remember?) troubleshoot broken behavior.
Regarding avih’s comment above, extensions are not like DOS *programs*, they are more like drivers in how they iteract with the internals of the host system.
May 4th, 2005 at 12:44 pm
Oh, hey, somebody acknowledged the existence of my pet bug!
I think it’s interesting how virtually every person who has developed extensions agrees that making maxVersion optional would carry more benefits than drawbacks, while those working at higher or lower levels on the framework (involved with administration of UMO or hacking Gecko at a low level, say) tend to see things differently — lower levels taking a neutral stance, and higher-level people taking the contradictory position.
We get intermittent reports of users unable to install Adblock. Still unsure of the exact cause, but I suspect that they’re trying to install with limited network access, leaving them unable to download the update.rdf file that we use as a workaround for rolling a new XPI just to update the maxVersion.
Axel: The problem with the maxVersion system we have is that, thanks to our poor ability to see into the future, it’s inaccurate, and those inaccuracies are causing extensions to appear broken to end users (unfortunately ironic, considering that the system was put in place to prevent broken extensions…). The concept itself is a valid one — a specific version of a tab extension might be made obsolete by a new checkin — but most extensions should be assumed to work on new platform releases, unless otherwise specified.
@Neil M., re “unsupported territory”: better to have a working-but-“unsupported” extension, or a “supported” one (whatever that means) that, for your pleasure and convenience, has been disabled/rendered uninstallable by Firefox?
One problem with having UMO change and redistribute extensions is that even for the open-source ones, Mozilla won’t usually have the right to use the artwork (think 3rd party Firefox builds), or to redistribute under the original name. This leads to fragmentation of the extension’s userbase. Not a big problem if the original is *never* going to be picked up again, but if the original author comes back, well… *shrug*. It is, as you note, a moot point — Mozilla doesn’t have the resources to do this on any scale, large or small, at the moment — but the problem (and consequences) of userbase fragmentation for competing extensions is a somewhat interesting one.
May 4th, 2005 at 12:56 pm
Nickolay: Ah, but the thing DictionarySearch was “doing wrong” amounted to a single line of code that needed to be changed, no?
maxVersion wouldn’t have actually helped for that particular example, since 1.0.3, as a point release, would have been considered “OK” under the most commonly used (1.0+) numbering scheme, which doesn’t expect or plan for behavior-changing minor version releases. Besides, as the lengthy discussion under the maxVersion bug establishes, maxVersion, as designed, is really only supposed to be protection for full point releases: 1.0, 1.1, 1.5, etc, since those full releases were what “we” thought would be running on Grandma’s computer. Unfortuantely, maxVersion was designed before the update system made minor point releases so widely distributed.
If you haven’t read the full commentary under the maxVersion bug, I recommend that you do, to get some insight into why it’s not nearly as much protection as it seems at first glance.
When such a discovery of an actual break occurs, it *ought* to be easy for the author to remotely enable maxVersion until a patched extension can be developed and uploaded. This should be a question of damage control, not paranoia-level risk prevention.
May 4th, 2005 at 3:11 pm
“Try to freeze interfaces that extensions use.”
No … don’t “try” …. DO IT!
I’ve been using Firefox for over a year and Mozilla Suite for 2 years before that. And the one thing that pisses me off more than anything else is that fact every new release breaks most themes and extensions.
This is utterly and absolutely absurd. Once Firefox and Mozilla hit 1.0 they should have had the basic infrastructuire in place — and quit screwing around with it.
Minor incremental releases ( from 1.0 to 1.1 ….. from 1.6 to 1.7 …. etc) should not break anything!!
May 4th, 2005 at 5:54 pm
Well, I can certainly see the need for security fixes to make breaking changes. NativeConnector (or was it NativeInterface) was a good example.
And I could take breaking changes from 1.0 to 1.1, even. It’s the 1.0.0 to 1.0.1 breaking that kicks my butt. :)
May 5th, 2005 at 9:24 am
> Ensure that mozilla.org has permission to distribute new versions
> of extensions listed on UMO that authors abandon
Taking over an extension that is not maintained anymore is a pain in the a** I have filed a bug in bugzilla somewhere but I guess this is very low priority …
Clearely something needs to be done as some heavily used extensions bit rot on umo.
May 5th, 2005 at 9:32 am
“maxVersion, as designed, is really only supposed to be protection for full point releases: 1.0, 1.1, 1.5”
I think that’s not true. mozilla.org could bump app.extensions.version for 1.0.3 as well, they didn’t do that not because of technical restrictions (I believe), but because they thought the number of broken extensions was very low.
Ben, I re-read the bug, and I think Wolf has explained everything very well. I’d like to add to what he says:
You make a few assumptions that are ungrounded at best:
1- negligible percentage of extensions break with new releases
2- those extensions that do break will be noticed by the “community of nightly testers” during development phase and extension’s author will release fixed version of extension or change maxVersion in update.rdf before “end-users” upgrade their apps.
For (2), I’d like to say that relying on just “the community” will never gain you good results. Unless there is a person who is in charge of doing X, there’s no guarantee it will be done. Leave alone the fact that nightly testers may not use all the 500 extensions available for Firefox.
Yes, maxVersion makes authors responsible for the testing, and they don’t like it. But it’s better than making the default action for extensions of “unknown” compatibility to allow installing them, which is what you propose in that bug.
I’m not saying that current implementation of idea is great, and I certainly can see your concerns here. I do believe, though, that breaking the browser for some non-techie people, just because probability of that is low (even if it’s in fact low), is wrong.
In my opinion, allowing more people (UMO editors?) to bump maxVersion in UMO’s database can help. Although I remember an argument against this, made by someone of UMO staff before 1.0, iirc, that this isn’t right, because if the version is bumped, and the extension isn’t fully compatible, it causes problems to the author. How ironic.
(btw, the “remember the changes in 1.8” should be “remember the *tree* changes in 1.8” in my previous comment. It didn’t like the angle brackets.)
May 5th, 2005 at 12:36 pm
First, keep in mind that there are numerous ways for extensions to break: some that merely prevent certain functionality of the extension from working (let’s call these class 1), some that prevent the entire extension from loading (class 0), some that cause the browser to be unusable (class -1), and some that cause dataloss or profile corruption (-2).
It is, I hope, clear that having a maxVersion restriction kick in is functionally equivalent to a class 0 “breakage”, and is worse than a class 1 break. I do think that damaging breaks that go undetected by the community are quite rare. Perhaps not as rare as when the first comments in the bug were written, but still rare. Care to quote any examples? Virtually all of the breaks I’ve seen have been exposed by patches checked in to nightly builds.
Regarding having maxVersion targeting major point releases, the assumption has been that minor releases wouldn’t contain breaking functionality. The possibility was acknowledged, but not deemed likely enough to warrant much consideration. (IIRC this was before support for FVF strings like “1.0+” was checked in.) Anyways, I’ll quote Wolf himself:
Regarding point 2: Ideally, there would be an easy way for UMO admins to re-package extensions with a new maxVersion. My point with the “community testing process” is that by the time the milestone is released, compatibility is Known, not Unknown.
Heh. You do realize that a not-insignificant portion of Firefox’s success is directly attributable to the community surrounding it? For promotion of the browser, creation of extensions, helping maintain bugzila, even for development of the core, Firefox’s community is one of the first-order forces contributing to its ongoing survival.
Also, what makes you think that the fact that there is someone in charge of X means it’ll get done? There’s plenty of contradictory evidence to be found with UMO, on the extension-developer and backend-development and administration sides. The developer panel was what, nearly a year late? UMO’s goal of only hosting “vetted” extensions proved to be such a burden that their collection essentially froze in time, leaving outdated and, occasionally (*gasp*) broken extensions being served from UMO. As I believe you well know, uninstalling Adblock 0.5, as hosted by UMO, leaves users with a broken profile. Where’s the maxVersion protection?
The problem with “bump[ing] maxVersion in UMO’s database” is that there’s no “database” in which maxVersion may be bumped — it’s a text file in a ZIP, and PHP has rudimentary zip-reading and no zip-writing support built in. Because it would be an uncommon operation, they could probably get away with a shell script to unzip and rezip.
I agree that having extensions break browsers is not good, but I simply think that maxVersion, as implemented now, is causing more harm than good.
Of course, the really fun bit in all of this is that it’s too late to do it right. Too many 1.0 installs require maxVersion now; as I noted in the bug desc., “I also think that this should be dealt with ASAP, as the longer it
goes unfixed, the harder it will be to fix.” On the other hand, remote update.rdf support has made maxVersion optional in fact if not in name. We now have all of the hassle with none of the protection. Happy joy.
May 5th, 2005 at 4:16 pm
I think maxVersion should be replaced by maxTestedVersion. This way it’s not hardcoded that an extension will NOT work when the version is upped. It’s left for the browser/user to decide whether an extension[/theme] that was tested with 1.03 will also work with 1.04.
Seriously, a platform which requires its applications to be restricted by-definition to the current version (or earlier) ONLY is a bad platform. You just can NOT expect developers to keep updating their applications because the platform keep changing under their feet. A platform should be stable, and a basis developers can count on. Backward compatibility is such an important issue for applications and for the platform to succeed. For those of you who haven’t read Joel’s column on this issue, it’s a really good read: http://www.joelonsoftware.com/articles/APIWar.html
As it stands now, the platform forces an extension to declare that it will NOT work with any future version of the platform (that’s a direct implication of the compulsury existance of maxVersion). And this (currently) makes firefox[/gecko.mozilla/whatever] a bad platform which shoots itself in the foot.
May 6th, 2005 at 6:37 am
(In reply to Ben Karel)
* re maxVersion targeting major point releases. You seem to be missing the point. app.extensions.version is just a FVF string (i.e. major[.minor[.subminor[.buildid]]][+]), and extension with version V in FVF is compatible with given version of app, iff V >= app.extensions.version.
http://www.mozilla.org/projects/firefox/extensions/update.html says “In most cases, this pref will stay the same between minor versions.” Notice the “in most cases”. So it’s not maxVersion’s design/implementation problem that the a.e.v wasn’t bumped for 1.0.3. It’s a conscious decision of whoever is in charge of Firefox, preferring “state 1” for extensions that used window.__proto__ trick over “state 0” for all extensions in a minor upgrade.
In Wolf’s comment “major milestone” was just an opposite for “nightly builds”.
* re “by the time the milestone is released, compatibility is Known, not Unknown”. If that’s the case, why would you need to remove the maxVersion, if the “community” updates compatibility information for all extensions by the time of release?
* re “relying on just the community”. I am well aware of the role of Mozilla community. But do you think there would be any Firefox success if QA or coding was left to the community? Why does MoFo has dedicated QAs (Asa/Sarah/Marcia/Tracy) then?
As for what makes me think that the fact that there is someone in charge of X means it’ll get done, – it doesn’t. It’s just that (1) it’s more likely to be done and (2) as things are now, we don’t break users (users’ application, to be precise) if a person in charge doesn’t do anything by the release.
* re “uninstalling Adblock 0.5”. I believe that’s partially your (adblock devs’) responsibility. Although that doesn’t have anythinng to do with “maxVersion protection”. In fact you sabotage it by setting maxVersion to 10.0 in your update.rdf.
* re “bumping maxVersion in UMO’s database”. What you say is simply not true. There is a database at u.m.o which is used to generate equivalent of update.rdf for extensions that don’t orovide updateURL in their install manifests (that’s what called w@u in the bug, although it’s not really a webservice). Granted, this doesn’t work perfectly for users without permanent access to the Internet, but implementing your suggestion would simply break them anyway.
I don’t see why it’s too late to do something right. The problem is, it’s not clear what solution is better than what we have now. At this moment, I think that it’s important to implement Jesse’s #1 (like the mails which have been sent to authors that have an account at UMO with 1.0.3, only there should be a longer period between sending the mails and releasing the app).
May 6th, 2005 at 8:25 pm
I’d just like to higlight what I think is Jesse’s most insightful point, which seems to be getting ignored.
We need to admit that, in practice, there is a tradeoff between security and stability. A tradeoff between aggressively preventing extensions from breaking the browser and encouraging user’s to get security fixes.
Any arguments should keep this in mind. Statements like “I do believe, though, that breaking the browser for some non-techie people, just because probability of that is low (even if it’s in fact low), is wrong.” fail to address the security concern. I’d say it’s worse to encourage people to stay on old version without security fixes (High likelihood: happens all the time) than to allow breaking the browser (this level of incompatibility happens much less often).