Chapter 6. Packaging and Installing Applications-P2
6.2.3.4. Overlaying Mozilla files into your application
In the previous section, we described how to use the XUL overlay
technology to put information from your application into the Mozilla
browser. When developers use overlays in this way, they usually add a
menuitem or a new UI to the browser that provides access to the
application.
But overlays can also add interface elements and other data from Mozilla
into the application itself. In fact, each component in Mozilla imports a lot of
its own user interface from such XUL overlay mainstays as
globalOverlay.xul, tasksOverlay.xul (the file into which the
xFly menuitem is overlaid), and navigatorOverlay.xul. As you can
see when you look at the main browser file, navigator.xul, shown in
Example 6-7
, most user interface is actually brought in from these reusable
overlays. A relatively small percentage of all that appears in the browser is
defined within that particular navigator.xul file.
Example 6-7. Overlays in navigator.xul
<?xul-overlay
href="chrome://navigator/content/navigatorOverlay.x
ul"?>
<?xul-overlay
href="chrome://navigator/content/navExtraOverlay.xu
l"?>
<?xul-overlay
href="chrome://navigator/content/linkToolbarOverlay
.xul"?>
<?xul-overlay
href="chrome://communicator/content/sidebar/sidebar
Overlay.xul"?>
<?xul-overlay

At the beginning of the book, you had to create RDF files that would
describe your application to Mozilla. Special entries also needed to be made
to the installed-chrome.txt file in the chrome application
directory. These entries are just two of the most common ways to address
the chrome registry, which is what Mozilla uses to persist configurable
aspects of the browser and its other applications.
6.2.4.1. Where is the chrome registry?
The chrome registry is not a single file and it's not stored in a single place.
Rather, it is a distributed collection of data and interfaces for data
manipulation. The data itself generally lives in RDF files, many of which are
in the chrome application directory. The chrome registry APIs --
principally nsIChromeRegistry -- are used by installation scripts when
they register new software, by the skin-switching UI, and by the language
selection facility. The chrome registry is the means through which packages
are registered.
In some cases, especially when you create and debug your Mozilla
application, you may want to edit the RDF files that make up the chrome
registry directly. But more often, you can use external scripts, inline
JavaScript, or the installed-chrome.txt file to get what you need
from the registry. Procedures for doing so are described in the section
Section 6.2.2
earlier in this chapter, and in the section Section 6.3.2 later in
this chapter.
6.2.4.2. Accessing the chrome registry in installation scripts
An install script is a required part of a software package like the xFly. The
two main functions of an installation script are the physical download and
installation of files in the package and registration of that software with the
chrome registry. Install scripts use functions from the XPInstall API to
install the files and functions from the chrome registry interface to handle
the latter, as seen in this snippet:

Example 6-8. Top level of the browser.xpi archive
install.js
bin\
chrome\
components
defaults\
icons\
plugins\
res\
Note that the high-level structure in Example 6-8
parallels the installed
browser's directory structure very closely. The bin directory at the highest
level of the archive corresponds to the Mozilla application directory. On
Unix, this directory is actually called bin, where all of the resources are
stored. On other platforms, the installation puts these resources in the
application directory itself.
In the case of the Mozilla browser, the XPIs manage the transfer and registry
of all components -- the chrome files in the JARs, the executables, the
default user information, and the libraries. As you will see in the installation
script, the contents of the archive are installed onto the filesystem in much
the same way as they are stored in the archive itself, although it's possible to
rearrange things arbitrarily upon installation -- to create new directories,
install files in system folders and other areas, or execute software that
handles other aspects of the installation, such as third-party installers.
6.3.1.1. XPI example
When the items to be installed are very simple, XPIs may contain nothing
more than a single executable and the install script itself, as shown in Figure
6-5. In this figure, the WinZip utility has been used to display the contents of
a XPI that installs a text editor on a Win32 system.
Figure 6-5. Simplest XPI archive

•
Can install anything via XPInstall API
•
PKZip-compressed
•
May contain one or more JAR packages
•
Mozilla installation
•
Used for new packages
The characteristics and usage of a JAR are:
•
Contains only the resources themselves
•
Installed with an external script
•
May be installed inside a XPI
•
PKZip-compressed
•
Themes
•
Languages packs
•
Storage archive for installed components
Mozilla uses the presence of this internal installation script and not the file
suffix (which can be changed easily enough) to determine what type of
archive it is. Accordingly, JARs are most often used to install new themes
and new language packs, which can be done by using just a brief trigger
script on a web page loaded into Mozilla. When they contain new chrome --