Shipping a plugin as an extension

One of the new features that is available in Firefox 1.5 is the ability to place browser plug-ins in a Firefox extension.

Historically, most people have chosen to use an install.js script to install a plug-in. When this method is used, you can choose to either place the plug-in into the plugins directory, or place it into your own directory and modify the Windows registry to let Firefox know where to find the plug-in. The downside to this method is that once the plug-in is installed, it might be difficult for users to upgrade, uninstall, or disable the plug-in. As of Firefox 3 (and any Gecko 1.9 based application) the use of install.js scripts is no longer possible and plugins must either be shipped as an executable installer or as an extension as described here.

Bundle structure

Toolkit bundles can be used for all add-ons including extensions, themes and plugins. Plugin packages should only need to package a small set of files in the follow structure in the xpi file:

install.rdf
plugins/
    pluginlib.dll
    plugintypes.xpt

The install.rdf file contains an install manifest that describes the plugin to the user. The library and scripting interfaces are held in the <tt>plugins</tt> directory.

Platform-specific files

It is possible to package multiple plugin libraries for different operating systems into a single xpi bundle. In the xpi you can use the following structure:

platform/
    Linux_x86-gcc3/
        plugins/
            libplugin.so
    Darwin_ppc-gcc3/
        plugins/
            libplugin.dylib

More specific information can be found in the platform-specific subdirectories documentation.

Install Manifest

The install manifest describes the plugin to the user. For a plugin the manifest only needs to be very simple:

<RDF xmlns="https://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:em="https://www.mozilla.org/2004/em-rdf#">
  <Description about="urn:mozilla:install-manifest">
    <em:id>[email protected]</em:id>
    <em:name>My Plugin</em:name>
    <em:version>1.0</em:version>
    <em:targetApplication>
      <Description>
        <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
        <em:minVersion>1.5</em:minVersion>
        <em:maxVersion>3.0.*</em:maxVersion>
      </Description>
    </em:targetApplication>
  </Description>
</RDF>

This contains 4 required pieces of information.

1. Every add-on must have a unique id. This can be in a guid form but the simpler email form is preferred now. You should aim to use a domain-name that you own and then your own unique short-name for the plugin before the @.
2. The plugin must have a name to identify the plugin to the user in the list of add-ons.
3. The version is fairly self-descriptive, it must be a toolkit version format.
4. The target application block says which versions of an application the plugin is compatible with. It includes the application ID and the minimum and maximum version of the application that the plugin works with. There can be multiple targetApplication blocks listed.

Providing updates

When plugins are packaged in this way they can make use of the built in add-on update system. This allows a remote update file to be read periodically and an updated version of the plugin offered to the user or to mark the plugin as compatible with a wider range of applications.

This is performed by including an updateURL in the install manifest. This should point to an update.rdf file on the internet which will include the updated versions and version information for the plugin.