1053594 - Investigate how to migrate add-ons and their settings during a reset

Status: RESOLVED WONTFIX

(Firefox :: Migration, defect)

Description

[Verdi [:verdi] Best to slack me]

Bug 1017919 proposes migrating add-ons and their settings and then disabling them during a reset. The intention is to save add-ons and their data that users' depend on while still being able to negate the effects of harmful or nuisance add-ons. Some concerns that came up while discussing this were:
1. Is it possible that by preserving an add-on's settings that we'd fail to fix problems the reset was designed for even though the add-on was disabled. For example, carrying over hijacked home page or new tab urls.
2. Is it possible that an add-on can re-enable itself even though it's been set to be disabled.

I made this bug confidential so that this could be discussed without publicly explaining how to circumvent any protections that we have or don't have in place.

Comment 1

[Matthew N. [:MattN]]

(In reply to Verdi [:verdi] from comment #0)
> Bug 1017919 proposes migrating add-ons and their settings and then disabling
> them during a reset. The intention is to save add-ons and their data that
> users' depend on while still being able to negate the effects of harmful or
> nuisance add-ons. Some concerns that came up while discussing this were:
> 1. Is it possible that by preserving an add-on's settings that we'd fail to
> fix problems the reset was designed for even though the add-on was disabled.
> For example, carrying over hijacked home page or new tab urls.

The case I'm thinking of is things like default/preferences/prefs.js in an extension. I'm not sure if they get applied when enabled or when installed.

> 2. Is it possible that an add-on can re-enable itself even though it's been
> set to be disabled.

Example of what we do for hotfixes: http://hg.mozilla.org/releases/firefox-hotfixes/file/afc361041e8a/v20130826.01/bootstrap.js#l19
If this is possible for any extension (which I suspect it is) then preserving them in a disabled state would allow them to re-enable themselves or at least run code to change behaviour like #1.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

(In reply to Verdi [:verdi] from comment #0)
> I made this bug confidential so that this could be discussed without
> publicly explaining how to circumvent any protections that we have or don't
> have in place.

We're not going to gain anything from hiding this conversation.

(In reply to Matthew N. [:MattN] from comment #1)
> The case I'm thinking of is things like default/preferences/prefs.js in an
> extension. I'm not sure if they get applied when enabled or when installed.

Disabled add-ons prefs are not loaded.

> > 2. Is it possible that an add-on can re-enable itself even though it's been
> > set to be disabled.
> 
> Example of what we do for hotfixes:
> http://hg.mozilla.org/releases/firefox-hotfixes/file/afc361041e8a/v20130826.
> 01/bootstrap.js#l19
> If this is possible for any extension (which I suspect it is) then
> preserving them in a disabled state would allow them to re-enable themselves
> or at least run code to change behaviour like #1.

That code runs on add-on re-install - and add-on can't cause itself to be re-installed (the hotfix system is what triggers the re-install in those cases).

Given those, I don't see any problems here.

Comment 3

[Matthew N. [:MattN]]

OK, thanks for looking into these two.

(In reply to :Gavin Sharp [email: [e-mail]] from comment #2)
> > Example of what we do for hotfixes:
> > http://hg.mozilla.org/releases/firefox-hotfixes/file/afc361041e8a/v20130826.
> > 01/bootstrap.js#l19
> > If this is possible for any extension (which I suspect it is) then
> > preserving them in a disabled state would allow them to re-enable themselves
> > or at least run code to change behaviour like #1.
> 
> That code runs on add-on re-install - and add-on can't cause itself to be
> re-installed (the hotfix system is what triggers the re-install in those
> cases).

I guess we'll be fine as long as we ensure that we don't trigger the install or upgrade code paths.

Comment 4

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

Per bug1017919comment7, this is no longer a requirement.