Services/Sync/Features/Addon Sync

From MozillaWiki
< Services‎ | Sync
Revision as of 15:07, 30 August 2011 by Gszorc (Talk | contribs)

Jump to: navigation, search
Please use "Edit with form" above to edit this page.


Addon Sync
Stage Definition
Status In progress
Release target TBD
Health Blocked
Status note Product Management needs to flesh out the feature page so that development can be unblocked.


Product manager Jennifer Arguello
Directly Responsible Individual Jennifer Arguello
Lead engineer Gregory Szorc
Security lead Yvan Boily
Privacy lead `
Localization lead Axel Hecht
Accessibility lead `
QA lead Tracy Walker
UX lead Alex Faaborg
Product marketing lead Jaclyn Fu
Operations lead `
Additional members Ibai Garcia (SUMO)

Open issues/risks


Stage 1: Definition

1. Feature overview

Add-ons are synchronized between sync clients.

2. Users & use cases

User installs an add-on on one browser. When a sync occurs, the add-on is automagically installed on other sync clients.

3. Dependencies


4. Requirements




Stage 2: Design

5. Functional specification

The Addon Manager maintainers would like to see Sync support all add-on providers so as to not introduce 1st and 2nd class providers. This will require some APIs.

The solution to this problem will consist of the following:

  1. Optional properties on add-on objects that describe the add-on for purposes of use in Sync
  2. Functions on AddonManager that take above properties and perform actions

For add-on objects, providers wishing to opt in to Sync will expose the following read-only, optional properties:

a string that describes data necessary to synchronize the add-on between clients. The format of the string is not defined, and is opaque to Sync code. A JSON representation of an object might be a good choice, to hold the data needed by the add-ons manager to install/uninstall an addon.
a GUID used to identify this add-on across Sync client instances. The GUID should be generated using Utils.makeGUID() from the Sync code. It is basically a Base64-encoded representation of 9 random bytes.

(These properties will need to be documented at

The AddonManager will support the following APIs:

getAddonBySyncGUID(syncGUID, callback) 
Obtain an add-on from its Sync GUID. Calls the supplied function when that add-on is retrieved. The callback receives null on unknown add-on or the add-on object (generated from the underlying provider) on success.
installOrUpdateAddonFromSyncData(syncData, syncGUID, callbackObj) 
Installs an add-on from sync data or updates the add-on so it has the information specified. Receives the data from the original add-on, the GUID it should be installed with, and an object describing callbacks to be invoked when specific events occurs. The manager will try to obtain an install record and then execute the install. The callbackObj contains the optional keys *onFailure*, *onInstall*, and *onNewSyncGUID* which can be functions that are called when those events occur. Each function receives *syncData* and *syncGUID* as their first arguments. *onInstall* will additionally receive the newly-created (or existing) add-on record and a boolean indicating whether a restart is required. *onNewSyncGUID* will receive as a 3rd parameter the new syncGUID for the already-installed add-on. As inferred from the callback definition, the function must be able to detect existing add-ons from the *syncData* and update the *syncGUID* of that add-on to the value specified.
uninstallAddonBySyncGUID(syncGUID, callbackObj) 
Uninstalls an add-on specified by its syncGUID. The callbackObj has the optional keys *onSuccess* and *onFailure*. Each receives as an argument the passed *syncGUID*.

Both of these APIs will require the AddonManager to have an additional relationship with the add-on providers (via APIs). The providers will need to provide a routine to install add-ons from *syncData* instances. And, the AddonManager will need to know how to call into these.

The add-ons Sync engine will discover the set of add-ons that can be synced via the following procedure:

  1. Query AddonManager.getAllAddons()
  2. Filter the returned list by items that have the *syncData* and *syncGUID* properties and are installed in the profile add-on scope (addon.scope == AddonManager.SCOPE_PROFILE)

The engine will process incoming records via the following procedure:

  1. Obtain the set of locally-installed add-ons (using above)
  2. For each incoming record: TODO

The Sync add-on tracker will install add-on listeners in the AddonManager and will listen for the following events:

  • onEnabled
  • onDisabled
  • onInstalled
  • onUninstalled

When these are observed, the tracker will:

  1. Verify the changed add-on is in the set of Sync-able add-ons (using same heuristics as add-on discovery documented above)
  2. Mark the GUID as changed
  3. This will result in a new record for that GUID being created automagically. The createRecord() procedure will create the necessary record which will be queued for upload to the Sync server.

On start-up, the add-on engine will query AddonManager.getStartupChanges() for changes applied on application start-up. These are not observed by Sync because they occur before Sync is registered and running. Even if Sync does catch them in its tracker, it should be safe to mark records as changed. The only side-effect will be a slightly different modified time.

AddonManager.getStartupChanges() will be queried for the following change types:


TODO: Sync should catch all startup change types (the constants above) and react to them. We may need an API or some kind of verification/test to ensure newly-introduced startup changes/constants aren't missed by Sync. (This is all because getStartupChanges() takes a type as a parameter.)

Open Issues:

  • What's the best way to reconcile installed add-ons with different Sync GUIDs? This will happen when two clients have installed the same add-on on different clients and then sets up Sync. The first Sync client will upload the records. Then, the 2nd will download that set and apply them. Should the Sync engine query AddonManager to see which add-ons (from the opaque *syncData* field) are not present or just call out into AddonManager and have it automagically recognize the dupe and update the Sync GUID? Either way, the Sync engine will need to know which Sync GUID disappeared so it can create a record saying the add-on was deleted/updated.

6. User experience design


Stage 3: Planning

7. Implementation plan


8. Reviews

Security review


Privacy review


Localization review




Quality Assurance review


Operations review


Stage 4: Development

9. Implementation


Stage 5: Release

10. Landing criteria


Feature details

Priority P2
Rank 999
Theme / Goal Experience
Roadmap Sync
Secondary roadmap `
Feature list Services
Project `
Engineering team Sync

Team status notes

  status notes
Products ` `
Engineering ` `
Security ` `
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `

Discussion notes from 2011-08-16:

  • add 'guid' column to 'addon' table in extensions.sqlite
  • add GUID support to AddonsManager (have it automatically generated, 12 chars base64url)
  • findings addons shouldn't count as daily update pings, or if they do, is it a problem?
  • generate one record per app per addon, silently drop records from other apps and unknown addons (unknown to AMO)
  • add option to locally disable enabled state sync (the "web developer case") in about:config