1010234 - Disabling a bootstrap add-on calls 'shutdown' on the add-on even if we haven't yet called 'startup'

Status: RESOLVED DUPLICATE of bug 1461062

(Toolkit :: Add-ons Manager, defect)

Description

[:Irving Reid (No longer working on Firefox)]

During manual testing for bug 760356, I noticed some odd errors in the log; it turns out that when we disable a bootstrap add-on, we don't check whether the add-on manager has initialized that add-on yet. This causes us to call the add-on's 'shutdown' method even though we have not yet called 'startup', which could cause the add-on to fail.

In this case, I had:

- change the "extensions.lastAppVersion" preference so that the 'Firefox is being updated' logic would kick in
- cleared the "extensions.shownSelectionUI" preference, so that the selection UI would be presented
- Started Firefox; when the select add-ons UI was presented, I un-checked the 'cycle collector graph analyzer' add-on so that it would be disabled.

Because the selection UI runs before the add-on manager initializes the add-ons, we haven't called the 'startup' bootstrap method yet. When the selection ui sets addon.userDisabled to true, XPIProvider.updateAddonDisabledState calls the bootstrap 'shutdown'.


1400073486737	addons.xpi	DEBUG	Loading bootstrap scope from /Users/ireid/Library/Application Support/Firefox/Profiles/sngia9xd.debug/extensions/[e-mail]
1400073486772	addons.xpi	DEBUG	Calling bootstrap method shutdown on [e-mail] version 0.0.1
1400073486775	addons.xpi	WARN	Exception running bootstrap method shutdown on [e-mail]: [Exception... "Component returned failure code: 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED) [nsIComponentRegistrar.unregisterFactory]"  nsresult: "0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED)"  location: "JS frame :: resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///Users/ireid/Library/Application%20Support/Firefox/Profiles/sngia9xd.debug/extensions/[e-mail]!/bootstrap.js :: shutdown :: line 99"  data: no] Stack trace: shutdown()@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///Users/ireid/Library/Application%20Support/Firefox/Profiles/sngia9xd.debug/extensions/[e-mail]!/bootstrap.js:99 < XPI_callBootstrapMethod()@resource://gre/modules/addons/XPIProvider.jsm:4239 < XPI_updateAddonDisabledState()@resource://gre/modules/addons/XPIProvider.jsm:4354 < AddonWrapper_userDisabledSetter()@resource://gre/modules/addons/XPIProvider.jsm:6659 < apply()@selectAddons.xml:217 < gUpdate_show()@selectAddons.js:273 < showView()@selectAddons.js:21 < gConfirm_next()@selectAddons.js:243 < oncommand()@selectAddons.xul:1 < XPI_startup()@resource://gre/modules/addons/XPIProvider.jsm:1872 < AMI_callProviders()@resource://gre/modules/AddonManager.jsm:870 < AMI_startup()@resource://gre/modules/AddonManager.jsm:746 < AMP_startup()@resource://gre/modules/AddonManager.jsm:2313 < AMC_observe()@addonManager.js:53 < <file:unknown>
1400073486788	addons.xpi	DEBUG	Removing manifest for /Users/ireid/Library/Application Support/Firefox/Profiles/sngia9xd.debug/extensions/[e-mail]

Comment 1

[Dave Townsend [:mossop]]

I'm guessing this can only happen with the selection UI which is the only thing that runs at startup before we've loaded the add-ons. Isn't that UI going away?

Comment 2

[:Irving Reid (No longer working on Firefox)]

(In reply to Dave Townsend [:mossop] from comment #1)
> I'm guessing this can only happen with the selection UI which is the only
> thing that runs at startup before we've loaded the add-ons.

True for now; I'm OK with "wontfix/not important enough" if you want.

> Isn't that UI going away?

Opinions differ; bug 899173 suggests doing another run of the selection UI.

Comment 3

[Dave Townsend [:mossop]]

If it's going away then I think there isn't much point in spending time on it. Otherwise we should probably fix it.

Comment 4

[Kris Maglione [:kmag]]

Let's assume that it's not going away, for the time being. The auto-disable flag has been largely ineffective to date, so there are a lot of reasons we'll probably want to run the opt-in again in the future.