Features/Desktop/Add-on hotfix

Status

Team

Open issues/risks

• Do we need a security review?
  • Likely a superficial one
• Can AMO handle the increased ping load?
• Can mirrors handle the "instant" demand for an add-on across the entire user base?
• Would mirrors like this more than a point release?
  • Less data but a lot quicker uptake

Stage 1: Definition

1. Feature overview

There are many issues that affect our audience after release that shouldn't require a full Firefox update.

Firefox will have a hardcoded add-on id. When checking for add-on updates (every 24 hours), it will always check for a specific add-on id and install it if an update is found.

2. Users & use cases

• We ship a new feature (like http:// hiding) and the user response is extremely negative. We issue an update to the add-on that flips a pref back to old behavior
• We need to distrust a CA. We ship an update to the add-on that makes Firefox distrust it and users are silently updated within 24 hours
• We have a problem with add-ons that require a rebuild of add-on metadata. We issue an empty add-on
• We have an issue that only affects Italian builds. Rather than issue a new Firefox update to everyone, we ship an update to the add-on which only acts when the locale is set to Italian
• We want to blocklist a widely used plugin. We turn on crude click-to-play and whitelist it for known good websites
• We know that Netflix/Hulu/etc does bad user sniffing for a particular Firefox version. We issue an update that drops down a infobar telling users what is happening and to contact the site, or we ship the add-on that changes the user agent on the site while they work on a fix
• We want to speak directly to our users with a one-time marketing message / news flash. We ship an update to the add-on that pops up an infobar with the message and then never shows again
• We want to A/B test a UI pref on beta. We ship the add-on to x% of our population or ship it to all Beta users and have the add-on enable functionality x% of the time

3. Dependencies

• Leverages existing add-on manager
• Leverages existing add-on infrastructure
• AMO would see increased traffic, need to account for that
• Need processes around creating a stopgap update

4. Requirements

• Firefox should look for "updates" for a particular add-on id
• The add-on should opt-out of the compatible by default initiative
• The add-on should never be marked "incompatible" with a firefox version, causing a UI dialog
• The add-on will only do spotfixes between a particular version and the next version should make the add-on obsolete. For example, any hotfix applied to for Firefox 8 should be superseded by Firefox 9

Non-goals

• Ship new features to customers via add-ons
• Firefox core with functionality broken into add-ons
• Won't replace the need for software updates
• Users should be unable to uninstall hofixes
• Hotfixes are shown with special UI in the add-ons manager

Stage 2: Design

5. Functional specification

• Firefox should look for "updates" for a particular add-on id
• Firefox will check AMO for add-on updates if the add-on is already installed
• The add-on id will be hardcoded
• A pref will be set indicating the add-on has installed itself and the version. This gives a historical record and allows the add-on to uninstall itself if desired
  • We won't have the add-on uninstall itself for a particular version as Firefox would then redownload it again
• Firefox will track the last installed add-on version in a special preference. This allows the add-on to uninstall itself while preventing Firefox from reinstalling it
• The add-on should never tell the user it is incompatible

6. User experience design

• None required
• We should get sign-off on the fact that the add-on won't be treated specially and will show up in the add-on manager, can be disabled, etc

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

Things already vetted:

• AMO webservices
• Add-on manager general functionality

Things to note:

• Security fixes shipped this way will have way better uptake than a Firefox release
• Security fixes can be shipped faster / before we have all the info and undone just as quickly

Privacy review

• Check with privacy team to see if add-ons give additional metrics by default we need to be aware of
• Before issuing an add-on update get privacy team to sign off

Localization review

• Should ship with all locales
• Shouldn't be any localization by default
• Need to discuss with the l10n team how we could localize if an update needed it

Accessibility

• Shouldn't impact accessibility

Quality Assurance review

• QA needs to test the add-on is there
• QA needs to test the add-on works
• QA needs to test the add-on can't be uninstalled
• QA needs to comment on how this affects their testing matrix and load for a chemspill
  • QA should come up with the matrix substituting historical chemspill releases with the hotfix add-on

Operations review

• justdave needs to be looped in to answer the mirror questions
• Need to loop AMO admins in on the increase of data
• Need to loop metrics in as the add-on metadata (ADU, locale, disabled/enabled) may help them in other areas

Stage 4: Development

9. Implementation

• Tracking in bug 694068

Mossop: "I've been tinkering a little with the add-on hotfix code and have something that works and passes the basic tests I've written so far. I had to make a choice and this we need to make sure we're aware of the implications of that before I go much further. For looking up available hotfixes from AMO I can either use the metadata API call or the usual update check call. They have some pros and cons:

The update check call has been standard for a lot longer than the metadata API. Should we ever transition this to some other server it feels like the version check format is likely to need less change over time compared to the metadata API.

The metadata API only returns the latest version of an add-on, regardless of its compatibility with the current version of Firefox. This means that we wouldn't be able to have a hotfix for Firefox 9 available at the same time as a hotfix for Firefox 10 (unless they were the same add-on). The version check call I believe in AMO (and certainly possible according to the format) can return multiple versions of an add-on to get around this.

In terms of code complexity it ends up being slightly more complex to use the metadata API call for this, it's due to stupid reasons but I'd have to move some code around to make compatibility checking work right so making the patch more complex than perhaps we'd like.

The update check call includes a number of parameters in the url based on the existing installed version of an add-on. Since the hotfix won't actually be installed normally I'll have to stub these out with fixed values. Not really a problem but might look odd in some metrics.

The update check call is what drives an add-on's usage stats on AMO, not sure if that is a god or bad thing.

Based on all that so far I'm leaning towards using the update check call as it seems to suit our needs better right now."

Stage 5: Release

10. Landing criteria

• Need to test the add-on in a real-world scenario during aurora / beta

Feature details

Team status notes

Hotfixes which use this mechanism are currently stored at: https://hg.mozilla.org/releases/firefox-hotfixes/file