Firefox global extensions, again

firefox iconPreviously, I have written on deploying Firefox extensions globally, and using the Firefox Client Customization Kit (CCK) to customize Firefox for your organization.

Using the CCK involves creating a Firefox extension, and most likely, you’ll want to deploy it globally. A few commenters on the CCK post were confused about the details around that, so this post is an attempt to clear all that up.

Firefox extensions are distributed in the form of an .xpi file, which is really an archive of a bunch or files and directories. When you double-click an .xpi file (or otherwise tell Firefox to use it), Firefox unarchives the contents and copies them into the current user’s profile directory.

Before unarchiving the xpi and installing it in the user’s profile, Firefox prompts the user to make sure it’s OK to do this. This is not a good fit for extensions you want to seamlessly deploy to all your users.

So instead, you must install the unarchived extension in the global extension location, which for Firefox on OS X is:

/Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}

You cannot just copy the .xpi file there. If you do, users will still be prompted to install it because it’s still in its archive. Instead, you must unarchive the extension, then copy it there. I find the easiest way to do this is just double-click it and let it install in your local user profile, then copy the unarchived extension from your user profile to the global extension location — something like:


cd /Users/gneagle/Library/Application\ Support/Firefox/Profiles/cuak0rwz.default/extensions
cp -R myorg-cck@extensions.myorg.com /Library/Application\ Support/Mozilla/Extensions/\{ec8030f7-c20a-464f-9b0e-13a3a9e97384\}/

After you verify it works as you’d expect you can then use your favorite packaging and/or distribution tool to install the unarchived extension on all your managed machines.

Firefox global extensions, again

31 thoughts on “Firefox global extensions, again

  1. DB says:

    Haven’t tried Safari either, but it looks like you can just push out the files to a users home directory in: /Library/Safari/Extensions/

    One thing though is a plist file in there. Not sure if that would need updated or not.

    1. Then the obvious thing to try would be to create a /Library/Safari/Extensions directory (from the root of the the startup disk) and see if Safari extensions work from there…

  2. This works quite nicely except it is not invisible to the user. The first time Firefox launches after the global extension is installed it announces an add-on has been installed but since I select no to show it in the add-ons windows a weird empty dialog pops up.

      1. Dan says:

        Correct that is what I had in my notes from the last time to turn off the warning about the new-addon. I have a profile in the User Template I keep updated on each machine.

        Trick:
        Also have to add this line to the prefs.js file in the Users Template, ~/Library/Application Support/Firefox/Profiles/o20qa86c.default/:
        user_pref(“extensions.newAddons”, false);

  3. BuckJ says:

    Awesome write-up, thank you!

    How do you remove the extra bookmarks that Firefox inherently adds on? Such as “Most Visited”, “Getting Started” and “Latest Headlines”?

    B

    1. BuckJ says:

      I’m not exactly sure what’s going on with the CCK but I seem to have sporadic luck with it.

      First, it seems to have a mind of its own when it comes to the order it lists bookmarks in the toolbar. The order I arrange using the wizard is not the order I get when firefox opens.

      Secondly, how do you disable the import wizard? I know previous we could create that override.ini file within the Firefox application, but now that we’re moving away from that, what option does CCK give me to cover that?

      Thanks!

      1. There’s obviously things the CCK cannot do, or may not do exactly the way you want. I don’t know if the CCK can disable the import wizard — we haven’t had a need to do that. And we don’t provide any default bookmarks, either…

  4. joh6nn says:

    I have found that the CCK Wizard is a little wonky and flaky at times, so I have begun using a method similar to the one outlined in your Default Settings article. I am currently on a windows box, so I will use it as an example:

    Firefox creates the following directory during installation:
    C:\Program Files\Mozilla Firefox\defaults\profile\

    This directory contains files that will be used to construct new FF profiles. If you create an “extensions” sub-directory and load it with extensions, they will be installed for each new profile that is created. It is possible to pre-load the newly created profiles with default preferences (just modify prefs.js), and anything else that you might wish.

    This method has a number of benefits over using the CCK Wizard:

    * Changes can be made in bulk: While the CCK Wizard allows you to add default preferences and bookmarks, it only allows you to do so one at a time. The same is true for deletions and edits: one at a time. Managing the files directly in this directory allows for copy&pasting from existing sources.

    * Allows for creating defaults not covered by CCK Wizard, such as greasemonkey scripts, user styles, cookies, form completions, etc.

    * Extensions installed using this method can be both updated, and uninstalled. It is not possible for users to update or remove globally installed extensions. I have experienced odd/flaky behavior when attempting to remove or update extensions installed by the CCK Wizard.

    There are some drawbacks to this method as well, but by and large, i have found it to be more flexible and reliable than the CCK Wizard

  5. Greg, this is great. I implemented this today to keep users from seeing the update notifications. While it would be better if FF used it’s plist for these settings (and therefore could be set via MCX), this is certainly better than having to hack the .app bundle to set these defaults.

    Thanks!

    1. I have a question about this. I tried to create a default profile with the profile manager and install global extensions on our Macs here where I work (8,000 clients) and it worked but the extensions would not carry on to the actual user accounts. They showed up, but I could not replicate their settings. I wanted private fox installed and configured for every user globally, so I could lock down a lot settings with in Firefox.

      Anyone have experience with that?

      1. Not sure what you are trying to do with the profile manager, but as for global extensions — are you using the technique described here? (unarchived xpi copied to /Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/)? It’s not clear from your comment.

  6. Thanks for the response Greg. I had followed the instructions on the Mozilla kbase article on installing global extensions. This was a while ago so my memory may be hazy, but I think maybe now after reading your article I may have skipped the step of un-archiving them.

    All I can recall is that I got the extension to show up on every user, but I could not get the settings of that extension to replicate over to every user account. It basically locks down the preferences (about:config) and requires a specific password to access them.

    The higher goal is to not allow users the ability to install their own extensions, ie like foxyproxy and such.

    1. That sounds like perhaps an issue with how that specific extension operates. Maybe use the Firefox CCK to install the extension and and its preferences for all users?

  7. tim Kimpton says:

    Hi Greg

    Thanks very much for all these very useful topics and you are an inspiration to IT administration.

    This is what i have found with a ridiculous amount of emals back and forth the enterprise@mozilla.org mailing list and testing

    For clarification

    * The documentation is outdated and is incorrect causing mass confusion for
    enterprises:

    https://developer.mozilla.org/En/Developer_Guide/Customizing_Firefox#Includi
    ng_extensions_with_your_distribution_of_Firefox

    https://developer.mozilla.org/en/Installing_extensions

    * On Mac OSX Firefox 8 and above unpacked extentions need to be placed here
    Firefox.app/Contents/MacOS/distribution/bundles/

    * The extensions will load even if Firefox is launched in safe mode and
    cannot be disabled

    * A distribution.ini is not required

    * A js script as reported by Mike Kapley reported as a bug to Mozilla is not
    required

    * If extensions are placed here /Library/Application\
    Support/Mozilla/Extensions/\{ec8030f7-c20a-464f-9b0e-13a3a9e97384\}/

    as well you will get the trust prompts so do not put any global extensions
    in here any more and just put them in the location stated above.

    I hope this helps people out🙂

    1. Thanks for the info, Tim. You write: “On Mac OSX Firefox 8 and above unpacked extentions need to be placed here
      Firefox.app/Contents/MacOS/distribution/bundles/”

      That’s unfortunate.

      Since Firefox is distributed as a drag-and-drop application, the typical way of installing a new version of Firefox will have the side-effect of erasing any extensions you’ve installed at that path.

      This is why the global extensions location of “/Library/Application\
      Support/Mozilla/Extensions/\{ec8030f7-c20a-464f-9b0e-13a3a9e97384\}/” was useful — it was outside the application bundle, so it affected Firefox, no matter what path it was installed at, and was not overwritten by updates to the Firefox.app

      If this is truly the new location, this is a step backwards for enterprise deployments as it means that each new release must be repackaged by an administrator, and an end-user with admin privileges can easily (accidentally) wipe out your customizations.

      1. Tim Kimpton says:

        Hi Greg

        Thanks for your reply i completely agree and said the same thing to the enterprise mailing list. My topic funnily enough was Firefox 8 is a big step backwards.

  8. Tim Kimpton says:

    Hi Greg

    Mike Kaplys’ reply on the enterprise list.
    —————————————-

    Upon further testing, it has been discovered that distribution.ini
    cannot be used to set the value extensions.disableScopes

    I’ve opened a bug for this:

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

    The only workaround for this at this time is to create a file in the
    defaults/prefs directory and set the preference there:

    pref(“extensions.autoDisableScopes”, 0);

    Any filename with a .js will do.

    Also, the correct value to disable the feature is 0.
    ——————————————

    This does work but you still have to create the js file within the bundled application.

    Problem still as follows though if using this way rather than putting them in a directory called bundles within the application

    1. Addons get disabled if user is clever enough to launch FF in safe mode.

    2. You will have to push out another js file containing the disable scope settings with packaging mechanisms again anyway.

    Overall its rubbish but I can only get away with it because none of my users have admin rights and I have already packaged my bundles extensions ready just incase I need to package up FF again.

  9. Tim Kimpton says:

    I advise everyone reading this to join the enterprise mozilla list and voice the importance of this.

    This is my latest rant to them

    Guys any chance you can put in future firefox versions to put in the default prefs within every app bundle of FF to always not prompt for extensions placed here on Mac osx

    “/Library/Application\
    Support/Mozilla/Extensions/\{ec8030f7-c20a-464f-9b0e-13a3a9e97384\}/

    It was the case in previous versions and would take seconds to implement.

    Problem is being in an Enterprise any js or bundle directories admins creates within the app will get over written with new updated versions of FF!

    FF 8 is nuts for admins and I think a lot more care needs to be taken before carrying on this urgent road to reach version 2000.0 the fastest in browser wars!

    Thanks Mike for reporting the bug to Mozilla but its getting ridiculous now and I am going to have to keep shouting about it.

  10. tim Kimpton says:

    I have now unfortunately unsubscibed to Mozillas enterprise list.

    It is clear they are not at all taking Firefox in the Enterprise seriously which is a surprise seeing as most of us in the modern world spend most of our lives working, along with enterprises wanting the best of everything including browsers working with specific custom settings and extensions.

    Even though it clear there are some very dedicated people in there like Mike and Kev who do take these issues seriously and are helping greatly to get over these problems, unfortunately it seems the majority are not willing to acknowledge the importance of making global extensions working again in the Enterprise for future releases and requests to update past documentation to reflect the new changes required for global extensions has been ignored.

    I have been very patient for many many years for Firefox knowing that it is open source and patience is a virtue. Even though my comments made in the lists were aimed for constructive critisim with intent to improve Firefox for Macintosh users in the enterprise, these clearly showed frustration which has been my down fall😦

    It has been made clear that the list is there not to vent frustration and therefore any further comments i make in the list regardless if they are constructive, will lead no where.

    I will for now continue to use firefox 7 in 32-bit (to get this PDF extension working http://code.google.com/p/firefox-mac-pdf/wiki/Download?tm=2 whilst hacking the install.rdf) and pray for the day pdf.js comes out of experimental.

    I will need to now port all systems and settings to work with another alternate browser which will take a very long time for UAT.

    This truly is a sad day for the Enterprise

  11. RichieB says:

    Global silent extensions are still possible. They need to be placed unpacked in the /distribution/bundles directory. Unfortunately this mechanism is not widely known.The only official documentation is here: https://developer.mozilla.org/en/Extension_Packaging#Including_add-ons_in_a_customized_application

    Mike also mentions it briefly in http://mike.kaply.com/2010/08/05/creating-a-customized-firefox-distribution/

    My organization uses Windows 7, and placing extensions in C:\Program Files\Mozilla Firefox\distribution\bundles works great.
    In OS X I’m assuming the directory is /Library/Application\
    Support/Mozilla/distribution/bundles but I haven’t tested this.

    1. For FireFox 19, my cck extension (unpacked from the .xpi) does NOT work when placed into
      “Firefox.app/Contents/MacOS/distribution/bundles/”

      but DOES work when placed in
      “/Library/Application Support/Mozilla/Extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/“

      I’ve checked permissions etc.
      Have they reverted their craziness so that external extensions are the way to go?

      Only thing is, that the extension is disabled by default. You need to manually enable it in the Add-ons.

      Any way around that?

      Obviously that step makes this extension pretty useless for Enterprise distribution.

      In the mean time, I’ve decided to make most of my changes in a customised-defaults.js files located here
      /defaults/preferences/customised-defaults.js

      Along with an override.ini file.

      This works well for most settings I want to do, but does not do the default Bookmarks that we’d like to put in place.

      1. I’ve noticed changes along these lines in Firefox 19 as well, but haven’t had the time to investigate. I’d imagine Mike Kaply’s blog is the best place to check.

Comments are closed.