The Add-ons Manager and I are rather good chums

Back in… er… a long time ago, I wrote an add-on called Filter Extensions. I was just scratching an itch – I had more add-ons than the Add-ons Manager was designed to cope with. Turns out people like add-ons.

Because of that little add-on, one of my first projects after I started working at Mozilla was teaching the Add-ons Manager about outdated plugins. The theory was that since I had worked on that add-on, I should already have some background in working with the Add-ons Manager code. Hah… Yea, no, that didn’t help at all. That feature eventually shipped in Firefox 3.6, which now feels like an eon ago.

With a whole two Add-ons Manager related things under my belt, I must have earned myself a reputation for really loving anything to do with the Add-ons Manager. So late in 2009 I was asked if I’d like to help Dave Townsend with the re-write of the Add-ons Manager that he had been planning for some time (with Jennifer Boriss Morrow for UX, and Henrik Skupin for QA). It would be just a short project, helping out with the new UI – nothing major, I’d be able to get back to finishing my other project soon enough. Turned out that at that stage there was no UI yet… and it would take about a year for me to write it. The first very basic iteration was written during my Christmas holiday in Motueka, a few days later I threw away half the code due to a change in the (still young) UI design. We eventually shipped the rewritten and redesigned Add-ons Manager in Firefox 4. By this stage, the Wiki page containing the notes from our weekly meetings was so long that it often took several minutes to load. And sometime during that adventure, Dave made me a peer for the Add-ons Manager module. I say “sometime” because I don’t actually recall him ever telling me.

Fast forward to a few months ago, where I got the chance to break a third of all the unit tests for the Add-ons Manager. Okay, maybe that part wasn’t so fun… but solving the add-on compatibility problem was.

Apparently that (and everything else) went well, because then this happened:

Dave: Hey, so, wanna be module owner?
Me: Yea, sure.
Dave: Oh… I expected to have to convince you.

(Note: A mostly accurate summary, not an exact transcription.)

So here I am, (sub-)module owner of the Add-ons Manager. It even says so on a wiki, so it must be true!

So what’s this mean? Mostly it means more work for me – and certainly new challenges, which is partly why I so readily said yes. I’ve been thinking more and more about direction, code quality, and solving problems in the “hard” to “impossible” range – but that’ll come in a later blog post. For now, it’s business as usual. And I’m in the business of kicking ass fixing bugs.


4 thoughts on “The Add-ons Manager and I are rather good chums

  1. How difficult would it be for the moz devs to provide ‘shim’ layer/routines if they muck with the interface too much ?

    I’ve seen multiple extensions fail because the renamed the extension manager interface! Now of course it may have been done because the interface changed enough they didn’t want old routines calling the new interface with old params… but it seems like it would have been a ‘good idea’, to provide a compatibility routine…

    Now to NOT have to maintain um…’N’ compat layers… , you might consider
    1) marking an older interface ‘deprecated’, after 2-3 releases (still works, but issues a warning message that you can click on ‘click x to not see this again’, — but the user is warned that that extension isn’t being up updated, and they may have to deal with something.
    2) break off shim layers into *extensions*.. i.e. if I’m a user that wants to run
    an extension from 1.x, and shimming it into 10.x is costly, put it in an extension and only those who need that will incur the expense. The shim layers would have a list of which modules are using them and only those modules would incur expenses for the ‘shimmed’ functions…

    The above should give the FF team the freedom to move forward, while providing acceptable alternatives for things they don’t want to include in the new version.

    NOTE: Any solution in this area must be in place by the EOLife date for 3.6 (let’s be sensible, that’s where much of the incompat comes from).

    Also note — if the FF devs want the freedom to redefine the interface at will, they also need to provide the SHIMS, if they break compat. Personally, I would like to see the Shim group as a separate but blocking entity from the feature group, so the feature group doesn’t feel constrained in thinking about how to implement the shim when they do a new feature, but that _may_ not be practical. But it might if the Shim group — when blocked, gets assistance from the feature group in fixing/implementing the needed shims. There is no requirement that the shim operate with the same speed, but unreasonable degradation should be considered ‘bad’ (I say, unreasonable, as if you move to a HW-based algorithm somewhere, where as the previous stuff, with more flexibility had to use SW, well… there will be a price… )….

    But fixing ‘the addon-compat job CAN’T be 1 person’s job, that person needs to be able to ‘block’ release, until the appropriate shim code is written.

    Note, in some or ‘many’ cases, nothing needs to be done other than fix the way version numbers are done. It used to be X.Y.Z, X was major changes, Very likely internal interface has changed. Y was for possible changes — but old stuff _should_ work (at most with minimal changes), and ‘Z’, bug fixes, no internal Calling changes.

    Going back to a sensible version number scheme would likely help the issue, even if it meant doing a global reset from FF10 -> FFng-4.5, when I saw the version numbers jumping by major numbers every month, I thought, this was really going to kill the basis of FF’s popularity — the extensions — because extension writers can’t be full-time employees writing their extensions; they don’t get paid enough to be that.

    Another though — maybe Moz might consider providing a more formal extension source repo — I know they ‘usually’ have a previous versions (is that always the case now?, cuz I remember times in the past when it wasn’t and I had to beg the author for a previous version)…

    But it might make it easier for people to fork and submit patches back to a extension maintainer — and if they don’t want them, then just make a fork!…(or a spoon?)…

  2. Hi,

    Filter Extension is great, but doesn’t work on last version of Firefox.

    Do you works on the new version ?


Comments are closed.