14

I'm using Firefox 5, and I already know that extensions are situated in the extensions subfolder of the Profile folder... However, I need to find where is a particular extension (say, CoLT) located; the problem is that most of the extension folders are named by guid, e.g.

extensions$ ls
{232ac1d3-4d70-4919-8338-48c3d3f98afc}
{29c4afe1-db19-4298-8785-fcc94d1d6c1d}
{2bfc8624-5b8a-4060-b86a-e78ccbc38509}
{33f141c0-3703-4a4c-b459-cec618a7dafd}
...

Then again: "Starting in Gecko 2.0 (Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1) , XPI files are no longer unpacked when extensions are installed. Instead, the XPI itself is placed in the extensions directory, and files are loaded directly out of the package." (Extension Packaging - MDN Docs)...

And since XPI is basically a ZIP archive, grepping through the extensions folder looking for, say, the extension name: 

extensions$ grep -ri 'colt' .

... will return nothing.

So, does anyone know of a method (or an extension) to tell me exactly which XPI (or unpacked folder) is a particular extension located in/loaded from?

Just a student
  • 10,560
  • 2
  • 41
  • 69
sdaau
  • 36,975
  • 46
  • 198
  • 278
  • I know you already got answers a long time ago, just would like to add a comment about `zgrep`. Don't know about your system - on my Cygwin, `gzip` package also includes `zgrep`, which it's a simple wrapper script around `grep` for allowing grepping inside zip files. In your example, `zgrep -i 'colt' *` would do the job. To do the same as you, I usually zgrep as I said, then `grep -ir --include=install.rdf 'colt' *`, so I can check for both uncompressed and compressed extensions. Of course, the about:support answer is much easier, this way would only be better if you need that on a script. – Charles Roberto Canato Dec 31 '15 at 08:09

2 Answers2

29

Type about:support#extensions-tbody into your location bar - this will list (among other things) all your installed extensions along with their IDs. The extension ID determines the folder/file name in the extensions directory. Note that extensions aren't always installed in your profile - if in doubt, contents of extensions.ini in your Firefox profile should clear things up.

If you want to have it more "comfortable" you can paste the following code into the Browser Console:

var {AddonManager} = Components.utils.import("resource://gre/modules/AddonManager.jsm", null);
AddonManager.getAllAddons().then(addons => {
    for (let addon of addons.filter(addon => addon.type == "extension"))
        console.log(addon.name, addon.getResourceURI().spec);
});

This will use add-on manager API to display the names and install locations of all your add-ons.

Wladimir Palant
  • 56,865
  • 12
  • 98
  • 126
  • Awesome @Wladimir Palant - thanks a lot, especially for the "comfortable" JS code :) I knew there had to be something easier than grepping :) Cheers! – sdaau Jul 05 '11 at 10:20
  • Excellent advise. I am trying to uninstall the logitech setpoint addon which is a piece of junk I never asked for and can't remove! Stop being evil Logitech. Only your piece of code allowed me to locate its install location. Can't believe it was outside the profile folder in program files. Thanks. – Adamantus Sep 19 '13 at 08:10
  • 2
    @WladimirPalant `about:support#extensions-tbody` is a more to the point url for retrieving the list of installed Firefox extensions. That url will immediately show the list of extensions without scrolling, at least in Firefox 50. – Pro Backup Nov 20 '16 at 13:53
  • @ProBackup: True, this works. I changed the answer accordingly. – Wladimir Palant Nov 20 '16 at 14:22
  • 1
    The `Components` object is deprecated. It will soon be removed. Even nowadays, it does not have `utils` as its part. – StSav012 Aug 09 '19 at 14:19
  • @StSav012: The `Components` object isn't available to web pages, you have to run that code in browser context - meaning for example from Browser Console. Quite remarkably, this code still *almost* works after three years. The API has merely been modified to work with promises rather than callbacks. I'll update the answer. – Wladimir Palant Aug 09 '19 at 17:29
  • 1
    @WladimirPalant, that's exactly what I've done and what I've found out then. I'm using Firefox 68. – StSav012 Aug 10 '19 at 04:37
  • @ashleedawg: Nope, I just tested and it still works in Firefox 79. But it really has to be the Browser Console (Ctrl+Shift+J), and not the Web Console for example. – Wladimir Palant Aug 17 '20 at 13:10
1

Ah well, here's at least something, so I don't get tumbleweed again :) 

extensions$ for ix in *.xpi; do echo $ix; unzip -c $ix | grep -aoi ........colt.........; done
...
{e4a8a97b-f2ed-450b-b12d-ee082ba24781}.xpi
{e6c4c3ef-3d4d-42d6-8283-8da73c53a283}.xpi
content colt jar:chro
hrome://colt/content/
:chrome/colt.jar!/loc
...

... which should clearly point out that {e6c4c3ef-3d4d-42d6-8283-8da73c53a283}.xpi is the container of the CoLT extension..

Note that unzip -c unzips to terminal/stdout, with -a we force grep to do binary search, but as that may dump huge lines on terminal, we limit that with -o for "matching only", and then add dots with the meaning of "match any character" around the search term so we can see what's going on in the vicinity of the match.

Not amazingly user friendly, but at least it works :) Still hoping to hear a more straightforward method for this..

Cheers!

sdaau
  • 36,975
  • 46
  • 198
  • 278
  • Doesn't work for locating uncompressed XPIs (anyway, the OP just have to use this as a complement), but anyway a very good way of not having to recur to `zgrep`, as I do. – Charles Roberto Canato Dec 31 '15 at 08:11