Closed Bug 668159 Opened 12 years ago Closed 2 years ago

Installing extensions from the command line using the extensions folder broken


(Thunderbird :: Add-Ons: General, defect)

Not set


(Not tracked)



(Reporter: alex, Unassigned)


(Keywords: dev-doc-needed)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.803.0 Safari/535.1

Steps to reproduce:

1. On OS X 10.6.8 copy an extension xpi file (e.g. "enigmail-1.2-sm-mac.xpi") to ~/Library/Thunderbird/Profiles/xxx.default/extensions/
2. Start Thunderbird 5

Actual results:


Expected results:

Analog to Thunderbird 3 the user should be asked to install the extension.
Also see ("Global Installation"). This doesn't work either. I could not find any documentation about this changed behavior or on on how to install an extension on Thunderbird 5 using the command line.
What happens if you delete the extensions.* files first?
Thank you for the reply. Unfortunately, deleting these file doesn't help (tested it before):

cd ~/Library/Thunderbird/Profiles/cxrqfra5.default;\
rm -rf extensions*;\
mkdir extensions;\
cp /tmp/enigmail5/enigmail-1.2-sm-mac.xpi extensions;\
open /Applications/Thunderbird\
Joshua, can you confirm that this is a bug or has the plugin installation process been changed on purpose? In the latter case the above mentioned wiki page should be updated.
Could anybody from Mozilla at least confirm this bug? It's been reported 4 days ago. That would be sweet. Joshua are you on this?
official documentation is at how do they differ ?
Thank you for the pointer, that helped a lot. I'll summarize:

Version: Thunderbird 5.0
Environment: OS X 10.6.8

Steps that will reproduce the problem?
1. Copy an extension (xpi file) to %profile%/extensions/
2. Start Thunderbird

What is the expected result?
The user should get informed that a new extension will get installed (behavior of Thunderbird 3).

What happens instead?

Possible workaround:
Unzip the xpi file to %profile%/extensions/{%bundleid%}. This works with Thunderbird 3 and 5.

Any additional information:
Although the workaround works very well, Imho this change / (intended) regression should be documented somewhere (e.g. in the above mentioned wiki).
+ Environment: Windowses {XP, Vista, 7}.

Another possible workaround:
1. prepare .json files for extensions first (can be obtained from %profile%/extensions/staged after manually adding extensions to thunderbird until restarted to install them;
2. put .json's with extensions to %profile%/extensions/staged. If extension was unpacked on adding, it should be unpacked now too. This way most of extensions will left in packed form, which is less fs-capacious and resource-hungry.
So we need to update our documentation.
Keywords: dev-doc-needed
Hi, dear dev's!

I would like to add that this feature also effects the feature to install addons globally, as this was a neat and sweet feature i just have seen and wanted to try, i just found this thread about the problem.

using this (or making it work again) can make the firefox plugin-power even more attracting to businesses - where many users have to use the same plugins under different accounts.

i tried both of the following ways, i found on the net:

1. place .xpi files under C:\Program Files\Mozilla Firefox\extensions does not do anything as described in this tread before...
2. firefox -install-global-extension c:\xmarks.xpi does just start firefox also without installing the plugin 

this will make sense on any win7 machine since using an administrator-acc beneath a normal user acc or more than 1 user.

will sw fix it?
cheers, floppy
Component: General → Add-Ons: General

Installing extensions globally is now managed using Enterprise policies:

Closed: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.