;Sync will not synchronize non-XPI add-ons such as plugins, lightweight themes, and search engines. Sync will also not synchronize add-ons installed outside of the currently running profile.
|Feature functional spec=Like other browser primitives that have become syncified, A syncGUID field has been added to the underlying entities being synced will need a sync identifier. extensions SQLite database ({{bug|682027}} tracks adding . All extensions now have a syncGUID to the extensions SQLite database. This properties will need to be documented at https://developer.mozilla.org/en/Addons/Addrandomly-on_Manager/Addongenerated ID suitable for syncing.
New APIs will be added To track changes, Sync has written a component outside of the add-ons engine called the "Add-ons Reconciler." This provides what the Add-on Manager does not: a persisted state of add-on changes and limited state. It installs itself as a listener for Add-on Manager events. When things changed, it records that change and updates it's own minimal copy of the global state. These changes are persisted to disk in a JSON file file in the AddonManager as appropriateprofile directory.
TODO: we should formalize how the Sync engine gets informed of whether a restart is required to finish the record application. Do we catch this in the tracker observers or install observers local to the sync method of the engine? The add-ons Sync engine will discover subscribes to changes in the set of addAdd-ons that can be synced via the following procedure: # Query AddonManageron Reconciler to trigger instant sync.getAllAddons()# Filter At the returned list by items that are appropriate for beginning of every sync 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: # Verify the changed add-on is in the set of Sync-able add-ons (using same heuristics as add-on discovery documented above, if needed)# Mark asks the GUID as changed# This will result in a new record for that GUID being created automagically. The createRecord() procedure will in turn create the necessary record by querying AddonManager which will be queued for upload reconciler to reconcile its state with 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 runningworld. Even if Sync does catch them in its trackerThen, it should be safe to mark records as sees all that has changed. The only side-effect will be a slightly different modified time. AddonManager.getStartupChanges() will be queried for since the following change types: * STARTUP_CHANGE_INSTALLED* STARTUP_CHANGE_CHANGED* STARTUP_CHANGE_UNINSTALLED* STARTUP_CHANGE_DISABLED* STARTUP_CHANGE_ENABLED TODO: Sync should catch all startup change types (the constants above) last sync 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() requires a type pushes out sync records, as a parameter.) The first release will not include locales & dictionaries. follow up bugs have been filedappropriate.|Feature ux design=;May need some UX has stated that there will be no new UX for giving the user feedback when an this feature. Individual add-on ons may trigger UX when they are modified, but there is being updated due to syncnothing we can do about that.
|Feature security review=The feature follows the same security model as other sync engines: add-on records are encrypted using the Sync Key and the IDs for each add-on are randomly generated.
