Team LiB
Previous Section Next Section

Hack 22. Edit Configuration Files

Modify configuration files where it makes sense to do so, and ignore the rest.

Table 1-1 in the introduction to Chapter 1 describes the location of the two important file areas that Firefox uses: the install area and the profile area. This hack runs through the files in those two folders, pointing out which ones can be modified for good effect and which ones are pointless to modify. If changes are made to these files using the Firefox GUI, then a restart is rarely required. If files are changed by hand, as described here, then a full restart of the browser is almost always required and is always a sensible policy.

Note that on Windows, the %TMP% directory is also used. The self-extracting Firefox installer temporarily unpacks its files into that directory. On Linux, you must untar non-RPM install bundles by hand to an arbitrary temporary directory before install. On all operating systems, OS files, or at least desktop files, are also touched during install.

Many of the following files can be modified with a simple text editor, although few are designed with that in mind. Of the rest, mostly binary files, small tools exist that can expose their content. To get these tools, either compile Firefox [Hack #93] or explore the contents of a nightly build [Hack #92] .

The preference system [Hack #23] spans the install and profile areas. It is not discussed in detail here.

3.2.1. Files in the Install Area

Here is a breakdown of the install-area subdirectories. A file with a .xpt suffix is a binary XPIDL type library, similar in concept to Microsoft ATL type libraries. A .jar file is an archive in PK-Zip (.ZIP) format:


This directory holds all the user-interface content that is part of Firefox, including skins, themes, locales, packages, and associated resources. Such content can be present in a JAR file or spread over a further hierarchy of ordinary package folders. The installed-chrome.txt file is written by the installer and registers all bundled chrome packages. This file can be added to by hand, if a package is also copied in by hand, but beware of accidental syntax errors. This directory's parent directory exactly matches the top-level of the resource: URL scheme.


This directory is a set of generated RDF files derived from and duplicating all of the contents.rdf files to be found in the chrome. There is little reason to touch it. It is regenerated on startup if it doesn't already exist. It is also regenerated if the installed-chrome.txt file has been modified (touched) since the last startup.


This directory contains XPCOM components bundled with the standard install. They're not considered part of the core runtime libraries. master.ini and other odd files belong to the third-party Full Circle Talkback system that generates diagnostic information if a critical error occurs.


This hierarchy holds configuration items that are applied before any user profile items. The only extension normally contained in here is the default theme. Note that most preferences in here can be overridden via user.js in the profile area.


This directory contains references and scripts that apply to locked preference files [Hack #29] . Note that the JavaScript functions defined in prefcalls.js are the ones available for use in such locked files. The files in this directory can be modified with a text editor.


This directory contains extensions bundled with the standard install. The default theme, Firefox (default), is the sole bundled extension. The files in this directory can be hacked.


The Gecko Runtime Engine (GRE) is a semi-independent part of the Mozilla platform inside Firefox. It has its own specific preferences and defaults. These can be overridden normally with user.js.


For Linux/Unix only, this directory contains desktop XPM icons. The files in this directory can be modified [Hack #78] .


This directory contains installed plug-ins. Files can be copied here by hand. Type the URL about:plugins into the browser Location bar for more details.


This directory contains content required for the proper display of web pages, such as DTD entity definitions like   and placeholder images. The files in this directory can be modified.


This directory contains specs for bundled search-bar search engines. The files in this directory can be modified.


For Windows only, the files in this directory uninstall Firefox and record install logs. Don't touch the files in here.

On Linux/Unix only, the registry file in the install area is the do-nothing top-level registry of Firefox versions installed at this location. There can only ever be one version. This file is present only because there is a similar but more useful file on Windows.

3.2.2. Files in the Profile Area

Here is a breakdown of the profile area subdirectories. Any directory named Profiles or default that is a sibling of the Firefox (or firefox) directory is a profile for the Mozilla Application Suite Version 1.x. Also at that top level is the operating-system-wide registry.dat (mozver.dat and appreg on Linux/Unix) file, which records information about all Mozilla-based installations on the current host for the current OS user, and all profiles for that OS user. Inside the Firefox directory is the profile area proper. Two generated files for Linux/Unix located here shouldn't be touched.

The profiles proper have random characters in their top-level directory names. New profiles have eight characters of random digits; older profiles migrated to the current version have only three digits. These are salted directory names, a term borrowed from cryptography. Since files inside this directory are sometime updated in response to data delivered over the Web, it is safer if this directory's name is not publicly known. That reduces the chance of relatively obscure Trojan horse attacks, although the jury is out on whether such measures are excessive or not. These salted names also pose challenges for profile migration [Hack #25] .

The files in the salted directory hold all state (all information changes) derived from the browser session. All files can be hacked, except for .dat files in Mozilla Mdb/Mork formatthey are in too obscure a format to modify easilyand the XUL.mfl file, which is a binary cache of compiled chrome. Modifying the xpti.dat file is also useless. All files can be deleted and will be regenerated as empty files the next time the browser starts up. It is unwise to delete the certificate database [Hack #17] because then Firefox cannot visit secure websites. The localstore.rdf file contains the last known positions of all windows and any values specified with the XUL persist attribute. compatibility.ini is used as a timestamp flag for re-registering extensions [Hack #84] . Here are the other folders:

Cache, Cache.Trash

These folders hold the Firefox disk cache of web page content. It is harmless to delete the cache by hand. Change the location of the cache with this preference:

browser.cache.disk.parent_directory /* default = path to Cache parent */


These folders duplicate the function of the chrome directory in the install area. They're used if packages of any kind are installed in the profile. The sum of the two chrome directories is all the chrome that Firefox understands, unless clever developers add other locations to the chrome registry. These folders are also used by extensions to store content or state information as required.


This folder contains any extensions installed into the user profile. When the first user-selected extension is installed, the user is asked whether to put it in the profile area, where migration is possible [Hack #10], or in the install area. All subsequent extensions go into the same place.

Any directories named ImapMail, Mail, or News are installed by Mozilla Mail or Thunderbird, not Firefox. Extensions can also write files directly into the topmost profile directory where all the other stateful files are stored. Aggressively written extensions can modify any user-accessible file on the local disk and can modify the Windows Registry on Windows.

    Team LiB
    Previous Section Next Section