Do we need extension dependencies?

Ever since Firefox 2 we have vaguely supported a form of extension dependency. That is marking an extension as requiring particular versions of another extension.

The support is currently very limited and when a user tries to use an add-on that depends on something they don’t have they are pretty much left in the cold. While we tell them it requires something we don’t tell that what it requires or give them any easy way to download and install it.

Given this poor implementation it is perhaps no surprise that very few extensions make use of the feature (something like 50 listed on AMO, many of which are outdated). This raises questions over the cost of continuing to support this feature particularly now when we are undergoing large scale changes to the add-ons manager architecture to give better support to personas and jetpacks.

Before I made any final decisions I wanted to gather some feedback on what people thought about completely dropping the support for dependencies for now. We will always have the option to add it back again (even in a more functional state) at a later time should we decide it is worthwhile. Unfortunately it’s certainly not on the cards right now to complete the implementation as it stands and even leaving it as it is is costing significant work during the refactoring project.

Extensions can always handle dependencies themselves at runtime by testing for the presence of whatever they depend on. They can even then give the user a way to get what they need which makes for a far better user experience than the platform currently offers so I’m not sure I see a convincing reason to keep the feature as it is around for now.

19 thoughts on “Do we need extension dependencies?”

  1. Really too bad… Two of the 50 extensions with dependencies are actually mine and the user experience is really not great, true. I have an extension coming up with two dependencies (Adblock Plus and Weave) and was really getting concerned. At least now I know that I should be dealing with dependencies myself – now all I need is some useful UI that would be consistent across all applications (probably an extension manager overlay and something special for Fennec). So much about releasing an extension that doesn’t have any UI whatsoever (meaning also nothing to localize).

    I don’t mean to be bashing of course, I can fully understand this decision. You already have enough problems to solve and extension dependencies aren’t exactly the most simple one.

  2. The line “This addon requires additional items” which appeared (and still appears, I think) in the add-on manager window (and in my experience, often when not needed) was not a good system. I think that shoving the burden onto the extension writers’ (and users’) shoulders can make things clearer in this particular case. Of course there are extensions which require other extensions. In some cases it is rather obvious: for instance, gdata-provider is actually an extension to Calendar, so it can install in Sunbird, Thunderbird or SeaMonkey but in the latter two it is useless without Lightning. Many non-AMO versions of extensions “ported to SeaMonkey” require xSidebar, or used to, since it’s unclear to me whether this requirement still exists in SeaMonkey 2. And so on. I think that in case of dependencies an extension download page should mention “This addon requires for correct functioning”, and in addition, when using whatever it is that the “further addon” provides, the code should test if it’s there, and “degrade gracefully” if possible, otherwise pop up an error or even become a do-nothing addon, as circumstances allow.

  3. This could be solved on the Mozilla Add-ons site. There could be section/sub-page on the add-on listing that lists dependencies, and all the Add-on Manager would need to do is turn the current text into a link that goes there. One problem with Mozilla Add-ons though is that it doesn’t do ‘install all’ if there are multiple dependencies. Right now the collections feature is a good example of multiple install not being supported. A workaround would be to make a tool that allows users make a multi-item package (XPI) from public versions of add-ons on the site.

  4. I expect part of what makes this harder is support for adding additional add-on types, runtimes, and repositories. This could also mean a greater need for dependencies. For example: features bundled as an XPI, requiring a runtime (this could solve the bootstrapping issue); features requiring a library; etc. Of course, dealing with those scenarios isn’t necessarily an immediate need – so support could be added later.

    1. It does become a complete nightmare if you start considering multiple add-on types. Imagine a scenario where we support Jetpack like features that don’t require a restart to use. If we allow XPI extensions to depend on Jetpack features then all of a sudden you can’t disable/uninstall the Jetpack feature without a restart since it must disable the XPI extension.

  5. This is just my opinion, but I think if an extension author is going to require another extension be present, he can ship the set as a multiple package bundle. (Though it isn’t clear how well-supported that is, either.) If you require it, provide it – even in a slightly stale form.

    1. I’m a developer of some extensions (OutWit) that use the dependencies system. We shipped our addons as multiple items pack so that users always install all needed stuff. The only benefit for us is to prevent users from uninstalling extensions that are needed by others.
      Extensions dependencies system is an important feature, but I understand it’s not the priority and as we have events when extension are uninstalled/disabled, I think we could do without it.

    2. Why should I require the user to install a bundle if in most cases he already has the required extension? Not to mention that I am not aware of any way to publish an extension bundle on AMO – and that’s still the main distribution channel for extensions.

    3. This works as long as you’re the publisher of both addons. If you want to rely on another that you *don’t* own, this becomes more problematic.

  7. Well, maybe the reason there are so few extensions out there using the dependency system is that the current support is so bad?

    Can’t you just query the AMO api for the download URL of a needed xpi (or an update url in the install.rdf) to download and install it instead of showing an error message? That’s pretty much all you’d need to make the bad user experience a good one. (Well, updates could still be a problem, but I doubt that custom solutions in add-ons would really get that better. And there wouldn’t be a need for all these 50 extensions to develop their own dependency system.)

    1. Malte, querying AMO was the idea from the very start – but some features turn out everything but simple when you start thinking about the details. In particular, this one has lots of nasty edge cases that need to be considered (nested dependencies, circular dependencies, updates for an extension but not its dependencies etc. etc.). Given the current state of the add-on manager I can understand that nobody wants to solve all these issues just yet. But – sure, I would be glad if somebody did nevertheless.

      1. Dependencies would be useful to cut down on duplication – quite a few extensions ship jquery for example, having a common extension for that would be nice. Dependency resolution is a solved problem, see apt or yum.

        1. My own experiences of apt and yum say that this isn’t a solved problem at all. It is fine so long as you are working from a single repository where all of the dependencies are managed properly (and even that isn’t necessarily true of the Linux distributions). As soon as you start to use repositories from different people you get conflicting dependencies that make it impossible to install or uninstall anything. To take your example I could easily predict that different extensions would end up requiring different versions of jQuery, we can only install one version of an extension at a time so you end up in a place where installing one extension necessitates the uninstall or disabling of another.

          But this is besides the point. Even if we had an example of a perfectly working system and we knew how to represent the complications in a way that the user could understand this would still not be a solved problem, there would still be work to implement that in Firefox and as I’ve said right now that is not on the cards.

  8. Although I can understand your temporarily taking it out, I truly hope you will add a revamped version in the future–one which, including at the AMO site, automatically downloads missing dependencies, at least with user permission. That part is critical.

    I would also like to see the ability to share smaller dependencies such as JavaScript modules (if not components). I think such modularization would greatly inspire more and faster innovation, code reuse, collaboration (since people are motivated to report bugs, etc.), and support users adding more extensions, since they won’t notice as much of a performance impact with modules being shared. Besides this, I think the awareness that one’s extension’s APIs can be exposed can lead to more interesting extension interactions (e.g., if Lightning exposed its APIs, an extension could make its own interface to add events).

    As you make any move to Jetpack, I also really hope other rich support will not be dropped. Please don’t dumb down things, whether due to making APIs more accessible or for security! While many of the masses might not care (or think they don’t care) about power features, a lot of us got into Firefox and develop for it because of its powerful platform. If there’s anything that could ever kill Firefox, it is driving away developers with too many platform feature regressions (though I don’t think this particular case would be a very significant one, I am nervous about the herd going this route, as I know some can take a “let’s protect them from themselves” attitude which may be ok for the web, but not for trusted extensions if it means less powerful APIs; likewise, I’ve also seen even top and otherwise admirable developers be a little patronizing in assuming they alone know what’s good for the web and use that to justify neglecting bugs or dropping niche but well-loved features). “It’s the Add-on power, dummies!” 😉

    You can’t please anyone, no doubt, but hopefully one can try… I think extension dependencies (if done thoroughly) is very directly related to enabling that…

  9. For extensions in other languages (e.g. using PyXPCOM) a dependency for an extension providing that other language is going to be necessary. I’m not sure how much we really want to encourage this though (I like Python myself, but it adds a fairly big burden on the browser having a huge monolithic platform specific extension).

  10. Just an observation, but wouldn’t this have been a moot point in the old “install.js” days? This does raise the question of why this was deprecated. The RDF version of installation is warm and fluffy and “easy”, but it also lacks a lot of functionality, IMO. I do not see there being a “security risk” with install.js primarily because once an extension is installed, the JavaScript therein has unrestricted access to XPConnect, anyway.

    Here’s a real-world example illustrating the problem. I’m writing a new extension for Firefox 3.x for a contract job. The extension *requires* that Java Applets be available. How do I make my XPI test for the dependency? Good luck with that.

    As a result, I have to end up writing a bunch of tests on the browser-side itself before even offering the XPI for installation. Although there is a solution, it’s a butt-ugly one.

Comments are closed.