Standard disclaimer: Under no circumstances should you use this information to create a custom Firefox install and redistribute it to anyone outside your organization. If you want more information, you can consult the Mozilla Foundation Trademark Policy.

What tools do I need to work with the Firefox installer?

The primary tool you need is 7-Zip. I install the MozillaBuild package which gives me all the tools I need. Even though the Firefox Installer is NSIS based, we will not need to use NSIS for most customizations. I’ll talk a little bit about the end about what kinds of things you would need NSIS to do.

How do I unpack the Firefox installer?

The Firefox installer is created using 7-Zip. So you can grab any of the Windows installers that end in EXE and unpack them. Any of the Windows installers on the Firefox download page will work. Once you’ve downloaded the EXE, create a temporary directory and type:

7z x "Firefox Setup 3.6.3.exe"

This will unpack the contents of the installer so we can modify it.

How do I bundle my extension with the Firefox installer?

Bundling your extension with the Firefox installer is just a matter of putting it in the right place. Then when we package up the installer at the end, it will get installed along with Firefox. For most extensions, the right place is nonlocalized/extensions. Inside that directory, create a subdirectory that corresponds to the ID of the extension you want to preinstall with Firefox. Then unzip the XPI into that directory. You can find the ID by looking at the install.rdf file inside the XPI. You can add as many extensions as you want into the installer.

What are some useful extensions I can bundle with Firefox

I’ve created two extensions that create interesting things to bundle with Firefox. The first is the CCK Wizard. The CCK Wizard can be used to change various defaults in Firefox so that you can customize it for deployment in your organization. The second is Rebrand. Rebrand allows you to change the internal branding used in Firefox.

Can I change the names used in the installer?

Yes, you can change the names used in the installer. To do this, you need to create a directory called distribution inside the localized directory that was created when you unpacked the installer. Create a file called setup.ini in this directory. Here’s what it looks like:

[Branding]
BrandFullName=Mike's Browser
BrandShortName=Browser

BrandFullName will be used to replace “Mozilla Firefox” and BrandShortName will be used to replace “Firefox”.

Can I change the images used in the installer?

Yes, you can change the images used in the installer. In that same directory where you put the setup.ini, you can put two files, modern-wizard.bmp and modern-header.bmp. The first images corresponds to the large image on the first page of the installer. The second image corresponds to the small image that is used on later pages of the installer. You can use the linked images as a reference to know what size to make these images.

How do I repackage the installer?

To repackage the installer, first you need to zip up the changes that you made. Type:

7z a -r -t7z app.7z -mx -m0=BCJ2 -m1=LZMA:d24 -m2=LZMA:d19 -m3=LZMA:d19 -mb0:1 -mb0s1:2 -mb0s2:3

This will create a file called app.7z that has all the changes we made. Now we need to package that file with some other files to create the final EXE. We’ll need the file 7zSD.sfx which you can download from Mozilla. And we’ll need a file called app.tag which you can create. It looks like this:

;!@Install@!UTF-8!
Title="Mozilla Firefox"
RunProgram="setup.exe"
;!@InstallEnd@!

Once we have these files, we can run the command:

copy /B 7zSD.sfx+app.tag+app.7z our_new_installer.exe

to package them all as an EXE. Don’t forget the /B. It indicates that the files are binary so Windows won’t put an EOF marker on them.

Can I change the defaults that are set in the installer like the install directory or the checkboxes?

At this time, there is no way to change the defaults in the installer without rebuilding the installer. There’s a bug open on this with a patch, so hopefully this will be fixed for Firefox 4.

Can I make my totally rebranded Firefox coexist nicely with an existing Firefox?

There are a couple ways to do this. The easiest way is to use the -no-remote parameter when you start Firefox. This causes the Firefox you are starting to not connect to the Firefox that is currently running. When you do this, you have to specify a different profile using the -P parameter. Alternatively, you can change the internal identifiers that Firefox uses. Then it will be considered to be a completely different browser. If you choose to do this, you should be aware that you will not receive updates and there will be other side effects. This is not a decision that should be taken lightly. Also, your profiles will be stored in different locations as well. If you want to do this, check out the file application.ini in the nonlocalized directory. The variables you want to change are Vendor and Name. Again, you do this at your own risk.

What can I do if I’m willing to rebuild the installer with NSIS?

If you are willing to rebuild the installer, you can change things like the name of the entry in the Add/Remove programs list, as well as the install directory and other defaults. This is a nontrivial exercise because some of the required files are built as part of the Mozilla build proces and are not available in the build tree. If you’re really interested in doing this, you can contact Kaply Consulting and we can talk about it.

I hope this answered some questions folks have. If anyone has any more questions, please don’t hesistate to ask.

Unfortunately Mozilla removed the ability for an add-on to hide itself in Firefox 3.6.

Luckily working around this is very easy and will be included in the next version of the CCK Wizard. In order to make this work, I’m going to provide one option that hides the add-on. Lock and hide will no longer be separate. This seems rather logical since the lock option is pretty useless by itself.

Note that none of these options work unless the add-on is installed in the same directory where the Firefox executable is located.

• Updated for new Firefox 3.6 proxy panel
• Two CCKs can now coexist (Company Identifiers must be unique to each CCK)
• Bundling XPIs and JARs no longer uses XPI bundles – they are explicitly installed upon first run of the CCK (please test this if you bundle multple XPIs)
• All translated CCK Wizards should now be working
• First run screen added to CCK Wizard install
• A few bugs fixed

Some other items of note:

As I mentioned before, I’ve moved CCK Wizard development to Google Code. Please feel free to open up bugs there.

Going forward, I’m going to add the ability to do more locking down of functionality in Firefox. If you have specific needs, please open bugs in Google Code.

To close this post out, I want to answer a couple questions about CCK Wizard that are asked a lot.

What is the right way to install the CCK?

There are multiple ways the CCK can be installed based on your needs. I’ll go through all those ways.

Standard install – The XPI that is created by the CCK Wizard is just a Firefox extension, so as such it can be placed on a web page and users can simply click to install. You can get more information on how to do this from the Mozilla developer center.

In the Firefox directory – Extensions can be installed directly into the Firefox directory. Inside of the directory where the Firefox executable is located, there is a directory called extensions. Inside this directory, you can create a directory with the same ID as your CCK and then unzip your CCK into that directory. This is the only location where you can hide the add-on.

As part of a Firefox install – I’ve previously documented how to bundle the CCK in the installer and how to package the installer on Windows. These instructions still hold true.

Globally – There are designated locations in different operating systems where extensions can be installed and they are picked up by Firefox. You can get more information on these locations at the Mozilla Developer Center. This involves unzipping the CCK package in a specific location on the users hard drive into a directory that is named the same as the ID of the CCK. Using this method, you can manage the CCK package centrally and the user cannot uninstall the CCK from Firefox.

Via the Windows Registry – If you are on Windows, extensions can be installed via the Windows registry. This is documented at the Mozilla Developer Center. This involves unzipping the CCK package that you created to a central location and then adding a registry key that tells Firefox where to find the CCK. Using this method, you can manage the CCK package centrally and the user cannot uninstall the CCK from Firefox.

What do the options “Do not show this extension in the extension manager” and “Prevent the uninstall of this extension” do? They don’t seem to work for me.

These options only work if your CCK is located in the extensions directory where the Firefox executable is located.

If you have any more questions, feel free to ask in the comments.

Do you need to do even more customization of Firefox for your organization? That’s what we do. Contact Kaply Consulting.

Most interesting news on the CCK front is that I’ve decided to move it to Google Code instead of maintaining in the Mozilla trees. The URL is http://code.google.com/p/ff-cckwizard/. My primary reason for doing this is honestly that I’m not really contributing to Mozilla/Firefox proper anymore and messing with Mercurial isn’t worth it for me (I know, lame excuse.) It has some other advantages, though, like having my own bug reporting system and not having to get any reviews/approvals for checkins.

So if you have ideas/suggestions/bugs for the CCK Wizard, please open them in Google Code.

Also note that CCK Wizard is something I do on the side, so my time is limited. Contributions help. I know there are a lot of folks who depend on this for the business. Any and all love is appreciated.

CCK Wizard version 1.2.5

Here’s a summary of what’s changed:

• Dropped support for Firefox 2
• Added support for specifying sites where cookies are always allowed
• Added support for specifying sites to deny popups/installs/cookies
• Rewrote CCKService XPCOM Component to be a little cleaner
• Fixed problem where sometimes a created CCK wouldn’t install (ZIP path problem)
• Fixed problem where sometimes bookmarks weren’t created on first load
• Fixed problem where bookmarks weren’t created in the same order as specified in the CCK Wizard
• Made the additional help menu look better on Mac

Enjoy!

CCK Wizard 1.2

Enjoy!

FYI, I’m making a beta of the CCK Wizard available today for Firefox 3.

If you are deploying Firefox in your enterprise, educational institution, or even your household, you’ll want to check out the CCK Wizard (info at that link is a little dated right now).The CCK Wizard is an implementation of the old Netscape CCK that allows you to customize various aspects of Firefox and then contain all of those customizations in a single Firefox extension. Here are some of the things you can do

• Add an identifier to the user agent string
• Change the default home page and startup override home page
• Change the title bar text
• Change the animated logo
• Add a web page and tooltip used for the animated logo
• Add a help menu item that links to a web page
• Provide sites for which popups and XPInstalls are allowed by default
• Preinstall browser plug-ins
• Preinstall search engines
• Change the default search engine
• Add folders, bookmarks and live bookmarks to the personal toolbar
• Add folders, bookmarks and live bookmarks to the bookmarks folder
• Set default preferences
• Lock preferences
• Add registry keys (Windows only)
• Add certificates (See NOTE below)
• Set default proxy configurations
• Package other XPIs with your distribution
• Disable about:config

Note that if you customize Firefox using the CCK Wizard, there are certain restrictions on redistribution outside of your organization, especially if you add certificates. Read the Mozilla Foundation Trademark policies for more info, or contact licensing@mozilla.org.

And please let me know if you find any bugs.

I also mentioned customizing the toolbar in my last post. We’ll actually save that for a future post.

Now that we’ve seen how to create XUL overlays to modify menus, let’s try out a real world scenario to see what else we might need to do. Let’s say we want to remove the user’s access to “Full Screen” mode. (I have no idea why you would ever want to do this, but Microsoft provides it as a customization in their group policy, so someone must want it.) Removing the menu is the easy part. We look in the file browser-menubar.inc and see that the ID of the menu is fullScreenItem. So by adding this code to our overlay:
we make the menu go away.

But we have a problem. The user could also press F11 to use “Full Screen” mode. How do we stop that? Luckily key commands are also defined in XUL, so we can modify those. Most key commands are defined in the file browser-sets.inc. Searching through this file, we find: By simply adding this line to our overlay:we prevent the keystroke from working.

That was an easy one. Let’s try something harder. Let’s remove access to “View Source.” View Source can be accessed three different ways, the View menu, the keystroke Ctrl+U, and View Page Source on the page’s context menu. Let’s remove all three. We already learned how to remove the keystroke: What about the context menu? Removing items from the context menu can be done exactly the same way as removing items from any other menu – with hidden. The question is where do we get the IDs for items on the context menu. Similar to the main main and they keystrokes, it is stored it its own file, browser-context.inc. Here we see that the ID for the view source item on the context menu is context-viewsource so we can just add
to our overlay. OK, one last thing. Let’s remove the actual View Source menuitem. Looking in browser-menubar.inc we see:
Wait a minute. This menuitem has no ID? How can we hide it? Luckily we can put JavaScript into our XUL overlay as well. In cases where we don’t have an ID, we have to write custom JavaScript to do our work. Here’s some code that hides the View Source menuitem:

This code uses JavaScript to find the View Source menuitem and explicitly hide it. It does that by getting the length of the View menu popup (the number of items on it), and traversing backwards through the menuietems until it find the View Source menu. Then it explicitly sets the hidden attribute on the View Source menu. The reason we know this is the View Source menu is because we were able to look in the browser-menubar.inc to see other properties that are only set on that menu (command=”View:PageSource”).

So now you should have most of the tools in your toolbox to remove functionality from the Firefox menus using the CCK to create the XUL overlay.

First let’s talk about what you can change. It’s beyond the scope of this article to go into all the things you can change with XUL. If you want to learn more about XUL, you can check out XULPlanet. For enterprise customization, there are probably two main things we would want to do: disable something or make it go away. We already know how to do disabling, but how would we make the Options… menuitem go away? The answer is the collapsed attribute:

OK, so we know how to change the XUL, let’s find out what we can change. You’ll notice that in order to change the menuitem, we needed to know the ID of the menuitem. So how can we find the ID of what we want to change? For this, we need to understand a little more about how the Firefox UI works. Most of the main Firefox window’s UI is contained in a file called browser.xul. By looking through this file, we can find various parts of the UI and use our knowledge of overlays to change them. For instance, looking through that file, we find out that the ID of the toolbar is toolbar-menubar. So if we wanted to make the menu go away, we could simply add:


Note that not only did we need to use the ID, but we had to use the name of the tag (toolbar) as well. You’ll notice that the menu is not in browser.xul (you won’t find menu_preferences, for instance). This is because the menu is contained in a separate file called browser-menubar.inc. You can consider this file to be a part of browser.xul for our purposes.

If you’re having trouble finding some UI in the XUL file, try this. Go to the Mozilla 1.8 Cross-Reference and search on the text you are trying to find. For instance, we’ll search on “Error Console.” This will return a DTD file that contains the string for the menu item (we want the one that begins with browser). On the same line as the text, you’ll see an identifier that usually ends in label. For the error console, it’s


By searching on the label, we can find the exact place where it is used in Firefox. In this case, it points us to browser-menubar.inc. We can use the information there to create an overlay that disables or removes the Error Console menuitem.

In the next installment, we’ll learn how to customize the default buttons on the toolbar.

Unfortunately I didn’t respond quickly enough to the request for information, so my stuff is kind of tacked on to the end. Here’s the key message I wanted to get across (which wasn’t in the article):

The main thing we think has changed at this point is that we (IBM) are working with the Mozilla Community to try to get the community more interested in the enterprise things. In particular, we (the community, as well as IBM) want to help enterprises with customization and deployment of Firefox, as well as work to figure out what can make Firefox better for the enterprise.

I agree with the overall article though. More needs to be done to make Firefox enterprise ready. Hopefully anyone who wants to help with that effort will participate using the various avenues we have created.