The humble opinions of Dave Townsend
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…
Back in the mists of time I wrote some code to make nightly testers’ lives easier by giving them a simple preference to flip if they wanted to be able to install and use incompatible extensions. It’s been more than three years since then and the use of this preference has grown beyond its original use. It is now something recommended to regular users everywhere from forums to comments in news articles as a way to use their extensions in the new major Firefox releases.
Don’t get me wrong, letting users upgrade sooner than they otherwise might is a good thing, but the preference is a dangerous beast. It is pretty simple for a user to set the preference and then forget about it leaving them able to install incompatible extensions that break their Firefox without realising it. This costs Mozilla time as well since we get quite a number of bug and crash reports to look at that turn out to be caused by extensions that are dutifully marked incompatible with the user’s Firefox.
We’ve been mulling over ways to change this for a while but now we’ve actually gone and done something about it. We still want nightly testers and early adopters to be able to use incompatible extensions if they need to but we also want to make the preference not be a one shot deal that lasts till the end of time. The plan we’ve come up with is to change the preference’s name with the Firefox version, so for Firefox 3.6 (and all security releases) the preference will be extensions.checkCompatibility.3.6. When switching to a future 3.7 testers and users will have to set a new pref extensions.checkCompatibility.3.7 to say they still accept the risks of running with incompatible stuff.
Nightly users will have to make the changes slightly more often since the preference will also track whether the version is one of the development alphas or betas, so for the 3.6 betas the preference would be extensions.checkCompatibility.3.6b, for the current trunk extensions.checkCompatibility.3.7a. These are just normal preferences of course, if you frequently switch between different Firefox versions you can just set both necessary preferences. The change should land on the trunk in the next day or so and then the 3.6 builds a day or so after that.
There is just one oddity, if you’re testing nightlies and you update to a build with the change then you likely won’t notice any of your extensions disabling themselves, that won’t happen till either you toggle the pref or you switch to a build with a different Firefox version number in it.
Update: For more in-depth information this change was made in bug 521905.
As part of the ongoing work to bring basic support for lightweight themes (based on the ideas from the Personas extension) into Firefox 3.6 I’ve today landed the main UI parts that allow users to see and select between lightweight themes they have used recently. Dão landed most of the backend last week but we’re still waiting on the support for installing new lightweight themes before this feature will be truly usable in the development builds. For the time being here is a shot of what the UI looks like in the add-ons manager after you have used some lightweight themes.
The idea is that users will install lightweight themes from websites. The add-ons manager will include the most recent lightweight themes used to allow the user to use them again. For this release they are offered as a straight alternative instead of other installed themes. We’re going to replace the default icon there with something more themey.
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.
This week has been the Firefox work week where almost all of the team, including me, made our way to Mountain View. This pretty much means that you spend the entire week in meetings since when you’re remote it can be hard to keep in sync on everything. Of course this means that the amount of coding is pretty low for the week so there isn’t a great deal of progress to report here.
This week, Alex and I met to come up with a rough design for what this is going to look like now that we know that the doorhanger notifications we were hoping for aren’t going to make Firefox 3.6.
