Pin extensions

[CafeImports]

I'm not seeing a way to enforce that extensions be pinned. Is that something that could be added, whether as part of the Extension Management JSON options or somewhere else? I'm using this to push out a Password Manager extension to our users and I'd like for it to be easy to find, meaning pinned right off the bat rather than having to tell them to go find it and pin it.

[mkaply]

I'm fixing this here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1813108

Hopefully something in the next version of Firefox.

[lanmaster53]

Hey @mkaply,

I asked about this feature in a post at https://www.reddit.com/r/firefox/comments/135w9rs/automating_pinning_extensions_to_the_toolbar/ where I was told it would be in version 113. I've reviewed the code changes and tested it thoroughly in 113.0.0, 113.0.1, and 113.0.2, but it doesn't appear to be implemented yet. It also isn't mentioned in the release notes anywhere, nor is it mentioned in the policy documentation. Has this feature been released yet? If not, any idea what version we will see this in? Thanks!

[mkaply]

So it's there, but I accidentally missed documenting it.

I just added it to the ExtensionSettings section:

https://github.com/mozilla/policy-templates/#extensionsettings

It's called "default_area"

Sorry about that. I'll get it more official in the next release

[lanmaster53]

That's what I gathered from the commit diff, so all of my testing was done with the below block added to my policy and none of the installed extensions (installed via Ansible playbook) were pinned to the navbar. See any issues with this? Do I have to also install the extension via policy in order for policy to apply? I assumed the * would make the policy apply to all extensions no matter how they were installed.

...
    "ExtensionSettings": {
      "*": {
        "default_area": "navbar",
      }
    }
...

[PSH-DF]

@mkaply, hi! Thanks for working on this. My company uses Firefox 115.0.3esr and I have the latest policy templates (5.1) installed. I am looking for the documentation on "default_area" referenced above and cannot find it on Github or the new Firefox documentation site.

I have two extensions that I am installing via Group Policy (Windows environment) and would like to pin them to the toolbar by default. It looks like I'll do that by adding JSON to the Extension Management policy, though I'm a bit lost from there on what that code should be. Could you point me to the latest documentation on this?

[mkaply]

Somehow I forgot to add this to the docs. It's a part of ExtensionSettings and it can have two values, navbar/menupanel

So what you see above your post is correct.

"ExtensionSettings": {
  "Extension_id": {
    "default_area": "navbar",
  }
}

[mkaply]

Yes, sorry, this isn't a global change. It only works explicitly for extensions installed via policy.

https://searchfox.org/mozilla-central/source/toolkit/components/extensions/ExtensionActions.jsm#517

We don't provide a way to change this globally. From the docs, it didn't look like other browsers do, but I could be wrong.

[lanmaster53]

Okay. That explains why it didn't work for me. I don't know about other browsers because Firefox is the only one I do this with.

[mkaply]

From your original post:

Is there any way to install extensions via a URI with policy?

You definitely can specify URLs for install

[lanmaster53]

I tried side-loading the extensions then using the following block in my policy, but it also did not work.

...
    "ExtensionSettings": {
      "[email protected]": {
        "default_area": "navbar",
      },
      "[email protected]": {
        "default_area": "navbar",
      }
    }
...

The reason I am side loading is because I want the extensions to be preinstalled during the build process, and not installed on first boot. The machine is used in situations where it sometimes does not have access to external network resources. When exactly does policy install the extension? If it happens during the build process, then doing everything via policy would work, but it is my understanding the policy isn't evaluated until Firefox is launched on the OS. Is this correct?

[lanmaster53]

This time I side-loaded the extensions then used the following block in my policy. Notice that the install_url variable is actually where the extension gets installed. This is where I side-loaded them.

...
    "ExtensionSettings": {
      "[email protected]": {
        "installation_mode": "force_installed",
        "install_url": "file:///usr/lib/firefox-addons/extensions/[email protected]",
        "default_area": "navbar"
      },
      "[email protected]": {
        "installation_mode": "force_installed",
        "install_url": "file:///usr/lib/firefox-addons/extensions/[email protected]",
        "default_area": "navbar"
      }
    }
...

This worked, and it looks like since the extensions were side-loaded during the build process, the policy applied when I started Firefox for the first time and skipped the install step because they were already there. @mkaply Does that makes sense based on the logic of policies?

[lanmaster53]

Okay... to complete my testing, I went with a 100% policy install and configuration of extensions without side-loading. As I suspected, this required a network connection to install the extensions when the policy was applied (Firefox is opened).

In conclusion, for anyone needing a pre-install solution due to connectivity issues, there are 2 options.

1. For a pure policy install, move the extension files to the image during the build process and make sure the policy uses the local file system URL for the install_url variable.
2. Side-load install the extensions during the build process and set the install_url variable to the local file system URL of the installed extension. This is basically the same solution as 1 except Firefox won't need to install the extension because it is already in place. I suspect this will save disk space as you won't end up with the extension's files in multiple places.

[mkaply]

Thanks for all this investigation, I really appreciate it.

I am going to see if I can just make the default_area work with non policy extensions.

[mkaply]

I just ran a quick test with this in ExtensionSettings:

{
"{816dd215-0e91-4621-9d89-3bac78798e6f}": {
"default_area": "navbar"
}
}

And when I installed

https://addons.mozilla.org/en-US/firefox/addon/extended-color-management/

manually, it was placed on the navbar.

So it does work for manually installed addons.

I'm wondering if it doesn't work for sideloaded addons because they are disabled by default?

How exactly are you sideloading?

[lanmaster53]

I'm sideloading using an Ansible task with the following configuration:

- name: Install extensions
  get_url:
    url: '{{ item.url }}'
    dest: '/usr/lib/firefox-addons/extensions/{{ item.id }}.xpi'
    mode: 0644
  with_items:
    - id: [email protected]
      url: https://addons.mozilla.org/firefox/downloads/latest/foxyproxy-standard/latest.xpi
    - id: [email protected]
      url: https://addons.mozilla.org/firefox/downloads/latest/wappalyzer/latest.xpi

All it does is download, rename, and place the extension files in the install location. Basically, it installs extensions without ever running Firefox, which is required since the Ansible build process is unattended and the finished image shouldn't require any manual configuration before being shipped for use. As shown in my testing, Firefox detects them as installed when it runs, but does't apply policy to them unless it thinks it also installed them.

Does this help?

[mkaply]

Do you know what install_location is in this case? Does it create an extensions directory in the Firefox directory?

(there are so many different ways to sideload/preload addons)

[lanmaster53]

It creates the directory and places them in /usr/lib/firefox-addons/extensions/{{ extension_id }}.xpi as seen in the dest variable above.

[mkaply]

Sorry, a couple more questions. I know it's been a bit.

Are you using the ESR?

Were the extensions placed in /usr/lib/firefox-addons/extensions/ enabled by default or did you have to enable them? (That seems like sideloading of extensions)

[lanmaster53]

I'm not sure what you mean by "ESR", but the extensions were detected by Firefox and enabled by default. I did not have to enable them.

[mkaply]

Extended Support release. It's a long term support version of Firefox. That's really odd. Firefox shouldn't enable extensions loaded in other directories by default. Time to do some Linux testing.

[lanmaster53]

Oh no. Please don't break my workaround. :-)

But in all seriousness, the directory I'm putting them in is not an "other directory". It's the same directory that Firefox installs them to in Xubuntu. Basically, I just do a manual install.

[mkaply]

I'm definitely not going to change anything, just want to understand the situation better :)

[mbze430]

I can't get this to work at all. I tried all the variations from the previous JSON suggestions, except for the ones that do all install of the extensions.

Here is what I have.

I am using Active Directory GPO to push out the install. using "Extensions to Install", "Prevent exensions from being disabled or removed". I am using the "Extension Management" to try to pin 2 of the extensions to the navbar/toolbar.

Here is the JSON inside of "Extension Management":

"ExtensionSettings": {
  "[email protected]": {
    "default_area": "navbar"
  }
}

is my JSON wrong?

[mkaply]

You don't need the ExtensionSettings part if you are already in Extension Management.

So just

  "[email protected]": {
    "default_area": "navbar"
  }

[mbze430]

Still nothing shows up; gpupdate /force & restarting Firefox. As you can see the "Remove Extension" is greyed out. So I know I have the right ID. But nothing is pin to the toolbar/navbar still.

Oh I am doing all this in the User Configuration since I need these to follow the users.

[mkaply]

What do you see when you go to about:policies? I'll test this locally.

[mbze430]

Here is what I got...  I also checked the Errors, but I don't know if this is from previous when I was using the "ExtensionSettings".  if this is old log, can it be cleared?  I also noticed that when you enable Extension Management it also turns on Extension Management (JSON on one line). But in the Extension Management (JSON on one line) it shows: "[email protected]": { Not sure if that is correct. Additional UPDATE: I downloaded the latest ADMX pack, still the same (I was only a month behind anyway) I tried to use the JSON on one line and I would get the error messages, "JSON string couldn't be parsed", "Invalid parameters specified for ExtensionSettings."

[mbze430]

I guess I forgot the {}... but! it still doesn't show up.

[mbze430]

should I open an issue report for this?

[mkaply]

I have it on my todo list, hoping to debug today or tomorrow.

[mbze430]

in that case I will just sit tight. Thanks

[ita-kevin]

Any update on this? We're trying to pin the Bitwarden extension via Group Policy and can't seem to get it working. I have this pasted into the Group Policy "Extension Management (JSON on one line)"

{"446900e4-71c2-419f-a6a7-df9c091e268b": {"default_area": "navbar"}}

It seems to show up in the About:Policies but nothing happens.

I saw further down @mkaply mentions it only works the first time the addon is installed, so I uninstalled the addon and allowed group policy to install it again but still no luck. It just won't pin to the toolbar.

[mkaply]

So I got the JSON wrong.

It should be

{
"[email protected]": {
"default_area": "navbar"
}
}

(Notice the outer brackets)

Also, it only works the first time the addon is installed.

[mkaply]

uhmmm is that a bug or expected behavior for the first time addon?

I'm checking. I think it's because we store the previous state of the addon in our database, so when it gets readded it gets the same position. (So like if a user moved the icon and then uninstall/reinstalled, it would stay in the same place)

[MlooneyHV]

Trying to get this to work as well on macOSX via a plist file. this is what I have so far but I can't get it working:

[mkaply]

So in your case, you should have a dict for default_area. IT should be under KeeperFF at the same level as installation_mode

[PSH-DF]

@mkaply, first, thank you so much for your support and tireless effort on something that may seem small. This setting is actually impactful. I manage IT for an organization of ~230 users and the ability to pin to toolbar is a great way to achieve consistency and minimize confusion for those staff who are less technically savvy.

One request I have would be the ability to force pin extensions to the toolbar, even if that extension is already installed. This would help a lot because for an organization where extensions are already in use and later pinned via Group Policy, the current behavior has no impact for anyone except new users who haven't launched Firefox yet. There could be a separate setting for "Extension Management (User can override)" if there is concern that users should be able to unpin, etc. as I realize my preferences may not be universal.

[mkaply]

I've opened a bug for this since i would be fixed in Firefox

https://bugzilla.mozilla.org/show_bug.cgi?id=1907385