725104 - Better handling of incoming add-on records for add-ons that aren't syncable

Status: RESOLVED FIXED

(Firefox :: Sync, defect)

Description

[Gregory Szorc [:gps]]

Currently, add-on sync blindly applies incoming records. Contrast this with outgoing records, which are checked for syncability (installed in profile, !foreignInstall, etc).

In some scenarios, this could lead to an error. For example, an add-on could be installed by a 3rd party application on 1 machine and Sync would attempt to modify this, failing due to insufficient privileges, for example.

I'm tentatively thinking that in the case where we delete or modify a local add-on from an incoming record, we should first ensure that add-on passes the isAddonSyncable() test. If not, we ignore the incoming record.

Or, perhaps we should just try to apply the changes [and mark this bug WONTFIX]. If it works, great, If not, we tried. What's the worst that could go wrong?

Comment 1

[Blair McBride [:Unfocused] (UNAVAILABLE)]

The Add-ons Manager handles the case you described. If you have an addon installed globally by a 3rd party, and then install a newer version of the same addon, the addon you installed will go in the profile (like a normal install). Technically there will be two copies of the addon, but only the one in the profile will be enabled (the globally installed addon will be disabled and hidden).

Was that scenario your only concern?

Comment 2

[Gregory Szorc [:gps]]

There is also the case of setting the enabled flag. It is possible that we may try to disable an add-on that is installed globally. This would probably fail. If it succeeded, it would be undesirable on a multi-user system.

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

The Add-ons Manager only acts on the current Firefox profile. So disabling a global extension will disable it only for the current profile, not any other users. And trying to uninstall it will throw an exception to the caller (ie, Sync), but that's it (it knows not to even try uninstalling it).

Comment 4

[Mark Hammond [:markh] [:mhammond]]

I believe this was fixed by bug 1312021 and bug 1275139.