How To Create A New Default Firefox Experience In Your Enterprise

This is a guest post by Mike Kaply.

As a developer or designer, how often are you satisfied with “off the shelf”? Templates are great because they offer a natural jumping off point for your creativity, but if it were a “take it or leave it” proposition – most of us would leave it.

The Internet browser is no different. Firefox and Chrome are the jumping off point for providing the essentials for navigating the web, but to really make it work for you, there’s a universe of add-ons and extensions to customize the experience.

Why not let the users just build out the version they want? Because the plain version may not meet the needs or expectations of the user. If you bought a Lady Gaga special-edition iPod, would you be satisfied getting the same iPod as everyone else or would you expect a little different style and maybe preloaded music? More to the point, if you’re a banking system handling millions of records of personally identifiable financial information, wouldn’t you want the browser a little more “locked down” than normal?

For those needing to go one step farther than the standard release of a browser, you can distribute your own version of Firefox tailored to the specific needs of your enterprise.

This post will detail various ways to do that and the information applies to all add-ons.

Use Case 1: Prevent users from seeing, disabling or removing an add-on

This solution is primarily for enterprise solutions where the need to maintain system integrity and security is vital. To include an add-on in a Firefox build and hide it so that it’s invisible to the user, it needs to be placed in the distribution/bundles directory.

• Start by making a directory called distribution in the same directory where the Firefox executable is located.
• Next create a subdirectory called bundles. Then create a directory with the same ID as your add-on and unzip it into that directory.

Important Note: If your add-on contains search plugins, they have to go in a different directory – distribution/searchplugins/common/. They will not be loaded if they are in your add-on.

Use Case 2: Users can disable, but not remove the add-on

If you’re like me, there are a few apps that are too important for me to remove, but sometimes they seem to interfere with a particular session or web site. To make sure your add-on is never removed, you need to put it in the extensions directory where the Firefox executable is located.

• Create a directory with the same ID as your add-on and unzip it into that directory.

• IMPORTANT: If you use this mechanism, your add-ons will be disabled by default. To override this, you’ll need to set the preference extensions.autoDisableScopes to 0 via a config file or by creating a new prefs file in the defaults/preferences directory. Setting this value via distribution.ini will not work.

• Setting extensions.autoDisableScopes to 0 will mean that any 3rd-party application will be able to install an add-on without asking permission. This recreates the behavior of pre-Firefox 8 versions, which was popular in enterprise solutions but also raises other issues – discussed in detail below.

• Note: Setting autoDisableScopes in a autoconfiguration file on a remote server (http://server/firefox_prefs.js) doesn’t work because it is read too late by Firefox. The only solution is setting it directly inside /defaults/pref directory.

In this scenario, I’ve had reports of users encountering two different prompts.

• Prompt 1 = “Select Your Add-ons” which shows some extensions saying that they will be disabled unless the user checks “keep.”

• Prompt 2 = “Another program on your computer would like to modify Firefox with the following add-on:” showing the new extension you’ve included in the build.

To get rid of Prompt 1, set extensions.shownSelectionUI to true. That tells Firefox the dialog was already displayed. For Prompt 2, you can set extensions.shownSelectionUI to true in the user.js file in core\defaults\pref

Use Case 3: Install add-on when a new profile is created, the user can disable or remove the add-on.

For this, you’ll want to use the distribution directory again, but with a difference.

• Make a directory called distribution in the same directory where the Firefox executable is located.

• Next create a subdirectory called extensions.

• Then create a directory with the same ID as your add-on and unzip it into that directory.

NOTE: You may be able to copy the {add-on-id}.xpi from from the profile into the {app-dir}/extensions folder like it was in the {profile-dir}/extensions folder but other add-ons will need to use the unpack method described.

Use Case 4: Install an add-on outside of the Firefox directory, but make it available in Firefox and the user can disable the add-on.

This scenario covers a lot of different cases. There are various directories on Windows, Mac and Linux where you can install an add-on and Firefox will pick it up. You can get more detail on those locations here.

A more common option on Windows is to use the registry. Rather than go into detail here, I’ll just point to another great article on developer.mozilla.org. IMPORTANT: If you use any of these methods, you run into theextensions.autoDisableScopes problem again. See Use Case 2 for more information.

Additional Discussion Around Scopes

Setting extensions.autoDisableScopes to 0 would enable any third-party add-on to install without your permission. From an enterprise standpoint, they are controlling Firefox in their environment and want this as their starting point, but in a more open environment – it can be a scary proposition. Here’s a more detailed explanation of add-on scopes and the two related preferences to help you understand better.

What are add-on scopes? Firefox divides the locations from which add-ons can be installed into four scopes. Each of these scopes can be turned on or off individually.

1. (SCOPE_PROFILE)
The profile scope refers to any add-on that is in the current profile directory.

2. (SCOPE_USER)
The user scope means any add-on that is referenced by the current USER’s registry entry or any add-on that is in the user’s extensions directory. On Windows, that is %appdata%\Mozilla\Extensions\{ec8030f7-c20a-464f-9b0e-13a3a9e97384}\. You can get more information here and here.

4. (SCOPE_APPLICATION)
The application scope refers to any add-on in the extensions directory where the executable is located.

8. (SCOPE_SYSTEM)

The system scope means any add-on referenced by a SYSTEM/MACHINE registry entry or any add-on that is in the system’s extensions directory. Windows does not have a system extension directory. You can get more information here and here.

To use the scopes as preferences values, just add together the values.
There are two preferences that use these scopes, extensions.enabledScopes and extensions.autoDisableScopes and their similar names leads to confusion.

extensions.enabledScopes
Introduced in Firefox 4, this scope is used to prevent Firefox from looking in certain locations to find add-ons. For example, if you are running Firefox from a USB key like SurfEasy or Portable Firefox, you would not want add-ons on the host computer to be loaded into Firefox. So you would set extensions.enabledScopes to 5 . That says “don’t read add-ons from the user’s directory or the system.” The default value for this preference is 15, which searches all locations for add-ons.

extensions.autoDisableScopes
Introduced in Firefox 8 as part of the effort to limit third-party add-ons, this scope is used to specify the add-on locations to be disabled by default. The default value for this preference is 15, which means add-ons are disabled in all locations if the user did not explicitly install them. If any external application places an add-on into the user’s profile directory, it is disabled by default.

Because these preferences are required very early in Firefox’s startup, they cannot be set in your extension. They can only be set by creating a .js file in the defaults/preferences directory. The JS file can have any name as long as it ends in .js. Setting them looks like this:

1. pref(“extensions.autoDisableScopes”, 0);
2. pref(“extensions.enabledScopes”, 15);

You cannot set this preference remotely using autoconfig files. It is recommended you only set this preference in a defaults/preferences file.

I hope this helps you on the path to finding the perfect Internet experience for your enterprise.

Mike Kaply is lead developer for Brand Thunder (http://brandthunder.com), a creator of extreme makeovers for the Internet browser. You can find out more about Mike at his blog, Mike’s Musings (http//mike.kaply.com).