1405202 - Disabled add-ons are no longer cleanly disabled/uninstalled

Status: RESOLVED DUPLICATE of bug 1405200

(Toolkit :: Add-ons Manager, defect)

Description

[Karl Tomlinson (:karlt)]

Prior to https://hg.mozilla.org/integration/autoland/rev/45d8844f0124
Tab Mix Plus would be disabled in a way that removed '\"tabmixScrollBox\",'
from "browser.uiCustomization.state" when updating Firefox from versions that
permitted add-ons.  I guess that was due to an uninstall mechanism.

When updating Firefox to a version after that changeset,
'\"tabmixScrollBox\",' remains leaving bug 1405200.

Comment 1

[Karl Tomlinson (:karlt)]

tracking-57? because, when updating from 56 to 57, legacy add-ons would not be
disabled in a way that cleanly removes their influence.  There is potential
for other problems from uncleanly disabled add-ons, and 57 is likely to
uncleanly disable many add-ons.

Comment 2

[Andrew Swan [:aswan]]

See also bug 1034394.
I believe the problem here is that Tab Mix Plus only cleans up its CustomizableUI state when it is uninstalled and in 57 it just became disabled.  This is annoying but there's not much we can do about it from the add-ons manager end (and this is a big part of why we have been so keen to get rid of XUL overlay extensions).  Your other bug covers what I assume is the more tractable problem of repairing the UI when it gets into this state.

Comment 3

[Andy McKay]

In bug 1405200 I'm recommending we reset the pref.

Comment 4

[Karl Tomlinson (:karlt)]

I investigated further and found that Tab Mix Plus removes tabmixScrollBox on
clean shutdown of the browser.  This is then also removed when disabled (not
uninstalled) before a clean shutdown.

I guess bug 1405200 must've occurred because the last run with 56 did not shut
down cleanly.

I don't think this report is a duplicate of bug 1405200, but I also don't know
whether forcing extensions through a clean shutdown is practical or sensible,
and my incorrect assumptions in this report make it kind of invalid.

Comment 5

[Karl Tomlinson (:karlt)]

(In reply to Michał Gołębiowski-Owczarek [:mgol] from comment #13)
> (In reply to Andy McKay [:andym] from comment #12)
> > This has nothing to do with WebExtensions, in that its only legacy add-ons
> > that have had the ability to flip this pref. Its the fact that the legacy
> > add-ons don't get uninstalled, they just leave the changes in the pref.
> 
> I may not understand all the implications but if the problem is legacy
> add-ons only get disabled, not uninstalled (and, as I understand, they will
> never get their uninstallation procedure fired as they no longer are allowed
> to work) could the answer for Firefox 56 -> 57 update be to simulate legacy
> add-on uninstallation but then re-add them to the "Legacy extensions" list
> without following their installation procedures? They could then be updated
> to a fully WebExtension versions if they get released in the future.

The "uninstall" hypothesis was an incorrect assumption on my part re bug
1405202.

The cause is similar but different: The pref is usually restored by this
add-on on clean shutdown, but remained in my testing because the last browser
run with 56 did not cleanly shut down.

Similarly, perhaps it's an option to run all disabled add-ons through a clean
shutdown, but I don't know whether that is practical or sensible.