The humble opinions of Dave Townsend
Done:
Firefox team shenanigans
True async reads for the add-ons manager
Compatibility overrides and compatibility updates
Figured out how to integrate webpage triggered installs
Next:
…
Done:
Catching up on a backlog of reviews
Planned out how to integrate the existing InstallTrigger code with the new EM backend
Handle migrating extension states from older/newer versions of Firefox
…
Done:
Worked through install and upgrade scenarios with Boriss
Implemented downloading and updating add-ons through the API
Implemented updating add-on compatibility on app upgrade
Next…
Done: Lost most of the week to sickness but trawled through some reviews that were blocking people’s work.
Next:
Downloads and updates in the add-ons API
Lost most of the week to sickness but trawled through some reviews that were blocking people’s work.
Done:
Intermittent test failure tracking
Post mortems
Wrote a patch to fix showing incompatible add-ons to users who have upgraded
Started setting up a project branch for the add-ons manager work
…
Need to change my working practices and start ignoring new emails unless they are critical so I can actually get more work done.
Done:
Identified and mostly fixed a regression in 3.6 involving executable files in XPI packages.
Worked with AMO to try to improve the capabilities of release notes for add-ons.
Figured out how to make the backend parts…
Done:
Started removing extension dependency support from the new EM backend.
Changed some of the API notifications to better represent add-ons that don’t require restarts.
Fixed a bug involving opening new windows after …
Done:
Fixed a minor bug with the new extensions.checkCompatibility.X.Y pref naming
Synced up with Unfocused and Boriss on the new add-ons manager UI
Submitted a list of things we need added to AMO’s API
Posted to the com…
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.
I have been remiss in not posting a status update about this in two weeks, but that is mostly because we have unfortunately had to slow down work on this feature. The problem is that a string freeze became necessary for all toolkit code (the code shared with the Firefox mobile browser and where this feature would have lived). Unfortunately this all came up over a small period when I was travelling long distances and having to take time out to satisfy immigration authorities that I wasn’t a terrorist intent on bringing down the U.S. government.
In the end there just wasn’t enough time to finalise the UI and be confident that it was correct before the freeze. This means that this feature isn’t going to make Firefox 3.6, however the intention is to continue working on it to get it into Firefox 3.7. It will just be on hold for a short time since I need to devote myself to Firefox 3.6 blockers.