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)
Toolkit
Add-ons Manager
Tracking
()
RESOLVED
INACTIVE
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.
Updated•14 years ago
|
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]
Comment 1•14 years ago
|
||
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.
Comment 2•14 years ago
|
||
(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: --- → ?
Comment 3•14 years ago
|
||
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.
Comment 4•14 years ago
|
||
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.
Reporter | ||
Comment 5•14 years ago
|
||
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?
Comment 7•14 years ago
|
||
(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
Comment 8•14 years ago
|
||
Blog'd: http://www.oxymoronical.com/blog/2010/05/Support-for-dropping-XPI-files-into-the-extension-install-locations Newsgroup'd: news://news.mozilla.org:119/nLqdnW7ZNqSdbGPWnZ2dnUVZ_ridnZ2d@mozilla.org
Comment 9•14 years ago
|
||
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: ? → -
Comment 10•14 years ago
|
||
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.
Comment 11•14 years ago
|
||
I guess you could look at the code here: http://mxr.mozilla.org/mozilla1.9.2/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#2915
Comment 13•13 years ago
|
||
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.
Updated•13 years ago
|
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
Comment 14•13 years ago
|
||
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.
Comment 15•13 years ago
|
||
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.
Comment 16•13 years ago
|
||
I'll try that Henrik, thank you.
Reporter | ||
Comment 17•13 years ago
|
||
(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?
Comment 18•13 years ago
|
||
(In reply to Ray Murphy (WildcatRay) from comment #17) > Is %ID% as listed in install.rdf? Yes.
Reporter | ||
Comment 19•13 years ago
|
||
Thanks.
Comment 20•13 years ago
|
||
That did the trick for now, thank you. It still would be better if the old way to install them would return.
Comment 21•13 years ago
|
||
Another question: I've just tried to install the Lazarus Form Recovery Addon but there is no ID in install.rdf - what now?
Comment 22•13 years ago
|
||
(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.
Comment 23•13 years ago
|
||
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
Reporter | ||
Comment 24•13 years ago
|
||
(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.
Comment 25•13 years ago
|
||
See https://developer.mozilla.org/en/Installing_extensions and https://developer.mozilla.org/en/Adding_Extensions_using_the_Windows_Registry
Comment 26•13 years ago
|
||
(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?
Comment 27•13 years ago
|
||
(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.
Comment 28•13 years ago
|
||
(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.
Comment 29•13 years ago
|
||
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.
Comment 30•6 years ago
|
||
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.
Description
•