1008565 - Bootstrap.js install function is called at the wrong time

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Jez]

I'm developing a bootstrappable extension, and when I copy its .xpi to my profile's extensions directory and start Firefox, the following events happen:
1. Firefox starts
2. My extension's install() is executed
3. A tab opens asking whether I want to allow the installation

It seems to me that 2. and 3. are in the wrong order - why is the extension being allowed to run privileged code *before* the user has allowed the installation?  This also has the consequence that the extension's install() function is unable to load the extension's content (like JSMs) because apparently its chrome.manifest hasn't been processed yet.  It seems like at the time when the user is asked to "allow the installation" of the extension, the extension is in fact *already* installed, but disabled.  If the user doesn't "allow the installation", the extension merely stays disabled.  However this seems like misleading behaviour to me.  If the user doesn't allow the installation, the extension should be *removed* and not just disabled.

This behaviour should be changed so that install() only gets run after the user has agreed to allow the installation, and after chrome.manifest has been processed, so that install() has access to its extension's content.  The extension should be *removed* if the user doesn't allow the installation, rather than just left there disabled.

Either that or the "Install add-on" tab that pops up should be changed to clarify that the user is not being asked whether to "allow the installation", but instead whether to "enable the addon now that it's already been installed".

Comment 1

[:Gijs (he/him)]

Dave, is this a known issue? And if not, how fixable is this? It seems interesting to me, but I'm not sure if there are architecture reasons that make this impossible/"really freaking hard".

Comment 2

[Dave Townsend [:mossop]]

(In reply to Jeremy Morton from comment #0)
> It seems to me that 2. and 3. are in the wrong order - why is the extension
> being allowed to run privileged code *before* the user has allowed the
> This also has the consequence that the extension's install() function is
> unable to load the extension's content (like JSMs) because apparently its
> chrome.manifest hasn't been processed yet.

This is always going to be true. We're not going to load the manifest until just before the startup method is called, regardless of whether the add-on is detected at startup or installed at runtime.

> It seems like at the time when the user is asked to "allow the installation"
> of the extension, the extension is in fact *already* installed, but disabled.

This is exactly what is going on. We don't currently have code supporting the case where an extension is present on the system but not "installed". The opt-in page is a bit of a hack to get us closer to what we really want.

Bug 640775 is probably what we need to complete before we could look to changing this.

Comment 3

[Jez]

(In reply to Dave Townsend [:mossop] from comment #2)
> (In reply to Jeremy Morton from comment #0)
> > It seems to me that 2. and 3. are in the wrong order - why is the extension
> > being allowed to run privileged code *before* the user has allowed the
> > This also has the consequence that the extension's install() function is
> > unable to load the extension's content (like JSMs) because apparently its
> > chrome.manifest hasn't been processed yet.
> 
> This is always going to be true. We're not going to load the manifest until
> just before the startup method is called, regardless of whether the add-on
> is detected at startup or installed at runtime.

Why is this?  In the case of my extension, one of my JSMs provides useful library functionality that would allow startup stuff to happen.  I don't want to redundantly duplicate that in bootstrap.js.

Comment 4

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.