Closed Bug 566373 Opened 14 years ago Closed 6 years ago

XPIs and JARs inside the profile folder aren't getting installed anymore

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INACTIVE
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: murph.0912, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [rewrite]) 

The old Add-on Manager would scan both the extensions folders in the user's profile and the application program installation folder for add-on .xpi and .jar files. When one or more were found, it would then offer to install the add-on(s) found in those folders. This capability is not available in the new Add-on Mgr. now in use on current browser Trunk/Minefield nightlies.

This is a convenient way for anyone trying to maintain multiple individual profiles with many common add-ons in each, but who does not want to install those add-ons globally. Also, it may be the only "convenient" way to install add-ons globally (in the browser program installation folder's extensions folder) since, IIRC, the command line option was discontinued.
Blocks: 461973
Keywords: regression
OS: Windows XP → All
Hardware: x86 → All
Summary: New Add-on Mgr. Should Be Able To Install Add-ons By Placement Of Their XPI & JAR Files In Extensions Folders → XPI's and JAR's inside the profiles extension folder aren't getting installed anymore
Whiteboard: [rewrite]
I had no immediate plans to implement this in time for Firefox 4 unless we see significant usage. I would accept a patch to implement it though.
(In reply to comment #1)
> I had no immediate plans to implement this in time for Firefox 4 unless we see
> significant usage. I would accept a patch to implement it though.

We don't really know how many people are using this method, at least not before the final version will be out. I believe that mostly admins of larger environments make use of this method. Dave, we should carefully think about fixing this regression for Fx4. I will set the blocking flag for now.

Dave, could we setup a blog post about this topic to gain feedback?
blocking2.0: --- → ?
Oh and I forgot to mention, it might be also a big win for our efforts with Mozmill and Add-ons testing. So we would only have to place the xpi's into the extension folder without having those to unpack ourself.
I don't believe admins of large environments do this since it causes the pretty confusing result of popping up an extension install dialog when you start Firefox, but sure we could blog about it and see what turns up.
Keep in mind the global installation of add-ons. Dropping the files into the program installation location's extensions folder is the convenient way currently available to do this. (I assume extracting the files into their folders which means having to know what the folder name is, may be the only other alternative available albeit much less convenient than being able to drop the file where it is to be installed.)
So I did some testing just now with the Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100524 Minefield/3.7a5pre nightly build.

* Take the extension you want to install, unzip the xpi into a directory named with the extension's ID.
* Copy that directory into the <program installation folder>/extensions/ directory, start Firefox with a new profile.

Result --> Extension is installed in the new profile.

* Create a new profile with no extensions
* Close Firefox
* Copy the extension's directory we created above into the <profile Location>/extensions folder (creating the extensions directory if needed)
* Start firefox with that profile.

Result --> Extension is now installed in that profile.

Mossop -- this is very important because this is how our automation works for Reftest class tests.  Reftests are actually little more than an extension which is copied into the running browser by the test's setup script.  Going forward (e10s etc) we will be doing the same with mochi-chrome, mochi-a11y, mochi-browser-chrome as well.  So this is critical behavior for our test automation harness.

However, the second method I outline above is what we use to achieve this, and that seems to be working fine, so I don't understand what the fuss is over here.

= Conclusion =
For test automation, we:
1. Unzip the extension xpi
2. Create a test profile
3. Insert the extension into the test profile by putting it into a directory whose name matches the extension ID
4. Start the application with said profile.

And that currently works, which is good.  What's the issue here?  Is this something that we intend to break and haven't yet?  Or is this only broken if you copy the .xpi of the extension into the directory?
(In reply to comment #6)
> Mossop -- this is very important because this is how our automation works for
> Reftest class tests.  Reftests are actually little more than an extension which
> is copied into the running browser by the test's setup script.  Going forward
> (e10s etc) we will be doing the same with mochi-chrome, mochi-a11y,
> mochi-browser-chrome as well.  So this is critical behavior for our test
> automation harness.

There is absolutely no intention to break this method of installing extensions.

> And that currently works, which is good.  What's the issue here?  Is this
> something that we intend to break and haven't yet?  Or is this only broken if
> you copy the .xpi of the extension into the directory?

What we used to support was just dropping the .xpi file directly into <profile>/extensions, not extracting it. On next startup Firefox would display the install confirmation dialog for that extension and if the user accepts extract it into place
At this stage I don't think we would block the release on this, that may change based on feedback from the first beta and I certainly would accept a patch to do this again.
blocking2.0: ? → -
Dave, could you point us to the code of the old manager which did that installation? That would be helpful for someone who decides to work on it.
As mentioned in the original discription this method of installation is the only easy way to install a global extension that can be used by all users/profiles on a system. While I have no problems with unpacking or renaming an xpi, I could never get my mother to do this. Also, it would be huge time saver for everyone installing global extensions.
Summary: XPI's and JAR's inside the profiles extension folder aren't getting installed anymore → XPI's and JAR's inside the profile's and the application's extension folders aren't getting installed anymore
I just stumbled accross that, too. Please put it back in since it's the only way to install mandatory global extensions for all users. We use this feature quite a lot, in both Firefox and Thunderbird (yup, doesn't work with Thunderbird 5 either) to deploy extensions to rougly 2.500-3.000 users. Not only extensions from AMO but also our own CI customizations of Firefox/Mozilla.
Martin, in the meantime just rename the XPI to %id%.xpi and put it into the same folder. That way it will be directly used.
I'll try that Henrik, thank you.
(In reply to Henrik Skupin (:whimboo) from comment #15)
> Martin, in the meantime just rename the XPI to %id%.xpi and put it into the
> same folder. That way it will be directly used.

Is %ID% as listed in install.rdf?
(In reply to Ray Murphy (WildcatRay) from comment #17)
> Is %ID% as listed in install.rdf?

Yes.
Thanks.
That did the trick for now, thank you. It still would be better if the old way to install them would return.
Another question: I've just tried to install the Lazarus Form Recovery Addon but there is no ID in install.rdf - what now?
(In reply to Martin Jungowski from comment #21)
> Another question: I've just tried to install the Lazarus Form Recovery Addon
> but there is no ID in install.rdf - what now?

    <em:id>lazarus@interclue.com</em:id>

That (excluding the <> tags) is the extension ID.
Changing the description here slightly. We lost this with the rewrite and it became more complicated to do with the changes to support packed extension installs. An additional complication is that the new extension manager doesn't really have support for installing extensions to anywhere except the profile folder. For this reason while I would still consider a patch to bring this feature back for the profile folder I wouldn't for the global locations. This was never the recommended or even the best way to do global installs for all users.
Summary: XPI's and JAR's inside the profile's and the application's extension folders aren't getting installed anymore → XPIs and JARs inside the profile folder aren't getting installed anymore
(In reply to Dave Townsend (:Mossop) from comment #23)
> This was never the recommended or even the best way to do global
> installs for all users.
 So, what was the recommended and/or best way? Is there someplace where this info might be available? Thanks.
(In reply to Dave Townsend (:Mossop) from comment #25)
> See https://developer.mozilla.org/en/Installing_extensions and
> https://developer.mozilla.org/en/Adding_Extensions_using_the_Windows_Registry

Too bad this doesn't work. I've tried all three directories on a 64-bit RHEL5 server with 32-bit Firefox 5.0.1 (downloaded from mozilla.org) and it didn't do anything. Renaming the extension $id.xpi and placing it in /opt/firefox-5.0.1/extensions did the trick but neither /usr/lib/mozilla/extensions nor /usr/lib64/mozilla/extensions nor /usr/share/mozilla/extensions seem to get scanned for extensions at startup.

Another question would be how to differentiate between Firefox and Thunderbird if they both look for extensions in there? Obviously I have different extensions for FX and TB so how would that work?
(In reply to Tony Mechelynck [:tonymec] from comment #22)
>     <em:id>lazarus@interclue.com</em:id>
> 
> That (excluding the <> tags) is the extension ID.

Thanks Tony that worked.
(In reply to Martin Jungowski from comment #26)
> Renaming the extension $id.xpi and placing it in
> /opt/firefox-5.0.1/extensions did the trick but neither
> /usr/lib/mozilla/extensions nor /usr/lib64/mozilla/extensions nor
> /usr/share/mozilla/extensions seem to get scanned for extensions at startup.

It says
/usr/lib/<vendor>/extensions/<appid>/
<vendor> is mozilla (or Mozilla, can't test right now)
<appid> is {ec8030f7-c20a-464f-9b0e-13a3a9e97384} for Firefox, or {3550f703-e582-4d05-9a08-453d09bdfdc6} for Thunderbird, or {92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a} for SeaMonkey.
Now I got it, thanks Steffen. It also has to be placed in there as %id%.xpi, which should probably be mentioned in there as well.
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.