RE: ​ Determine Enable/Disable state of WebExtn Installed via Registry

Sandeep Singh sandees at
Mon Oct 16 11:06:46 UTC 2017

Thanks Geoffrey, seems like I need to write a parser, for Profile0, parser can easily pivot on to “.default” and figure out  “nn0n2cq2” but for Profile1, since “.cs317” is randomly generated , figuring out the profile name here will not be straight forward(and I guess the name-lengths are also not fixed). Is there a way out for this was primarily my ask.


From: geoffreydebelie [mailto:geoffreydebelie at]
Sent: 16 October 2017 16:25
To: Sandeep Singh <sandees at>
Cc: Jefferson Scher <jscher2000 at>; dev-addons at; Vishal K. Gupta <vishal at>; Sachin Soni <ssoni at>; Pooja . <poo at>; Joydeep Majumder <jmajumda at>; dev-addons <dev-addons at>
Subject: RE: ​ Determine Enable/Disable state of WebExtn Installed via Registry

Hi Sandeep,

This info can be found in the profiles.ini file which is located at C:\Users\username\AppData\Roaming\Mozilla\Firefox on Windows.




Kind regards,

---- On ma, 16 okt 2017 10:07:54 +0200 Sandeep Singh <sandees at<mailto:sandees at>> wrote ----

Hi Jefferson,

Thanks for reverting back on this. When the user has multiple FF profiles and is running one of them, and with profiles names being random alpha-numeric-special characters, is there a pivot that I can use to fetch each profile name. It is only when the directory/folder name is available to me that I can go ahead and use the extension.json under that to fetch further details about the state of the extension.


From: Dev-addons [mailto:dev-addons-bounces at<mailto:dev-addons-bounces at>] On Behalf Of Jefferson Scher
Sent: 16 October 2017 05:01
To: dev-addons at<mailto:dev-addons at>
Cc: Sachin Soni <ssoni at<mailto:ssoni at>>; Joydeep Majumder <jmajumda at<mailto:jmajumda at>>
Subject: Re: ​ Determine Enable/Disable state of WebExtn Installed via Registry

Hi Sandeep:

The profile.ini file uses Default=1 to point to the current default profile. However, you are correct that the user may be running a non-default profile. And the user may be using more than one profile at a time using the -no-remote startup switch.

Generally speaking, any profile in use will contain a parent.lock file. This file should not exist in other profiles in which Firefox shut down correctly. It might exist in profiles where Firefox crashed.

Is there any foolproof indicator? I'm not sure.

The extensions data moved to extensions.json. It contains an addons array of individual extension objects. You can iterate over the array looking for id=(your extension id) and then checking the properties visible=true and active=false. Query whether you want to check for userDisabled = false, indicating the user disabled it themselves which might indicate you shouldn't nag them to enable it?

Dev-addons mailing list
Dev-addons at<mailto:Dev-addons at><>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Dev-addons mailing list