Install Manifests

  • Revision slug: Install_Manifests
  • Revision title: Install Manifests
  • Revision id: 8839
  • Created:
  • Creator: Mossop
  • Is current revision? No
  • Comment Add localized property

Revision Content

Introduction

An Install Manifest is the file an Addon Manager-enabled XUL application uses to determine information about an addon as it is being installed. It contains metadata identifying the addon, providing information about who created it, where more information can be found about it, which versions of what applications it is compatible with, how it should be updated, and so on.

The format of the Install Manifest is RDF/XML.

The file must be called install.rdf and live at the top level of an addon's XPI file.

Layout

The basic layout of an Install Manifest is like so:

<?xml version="1.0"?>

<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:em="http://www.mozilla.org/2004/em-rdf#">
  <Description about="urn:mozilla:install-manifest">
    <!-- properties -->
  </Description>
</RDF>

Some properties are required, some are optional. Some have simple string values, some are complex resources.

Required Property Reference

Your Install Manifest must specify these properties correctly otherwise your addon may not install.

id

The id of the extension, which is a:

  • GUID (generate using guidgen on Windows, uuidgen on Linux and makeuuid on Solaris) (Firefox 1.0)
  • {{template.Fx_minversion_inline(1.5)}} A string formatted like so: extensionname@organization.tld

The latter format is significantly easier to generate and manipulate. Firefox 1.5 has checking to ensure that your id falls into one format or the other and will refuse to install addons that have malformed ids.

Examples

<em:id>myextension@mysite.com</em:id>

<em:id>{daf44bf7-a45e-4450-979c-91cf07434c3d}</em:id>

version

A version string identifying the version of the addon being supplied.

For Firefox/Thundebird 1.0, the format must conform to the rules specified in Extension Versioning, Update and Compatibility. For Firefox/Thundebird 1.5, see Toolkit version format.

Examples

<em:version>2.0</em:version>

<em:version>1.0.2</em:version>

<em:version>0.4.1.2005090112</em:version>

Firefox 1.5 / XULRunner 1.8 - addons that do not use a valid version format will not be installed. The version format is different from, although backwards-compatible with, 1.0's.

For addons hosted on addons.mozilla.org - Mozilla's update website may repackage your addon and correct or reject malformed version strings.

type

An integer value representing the type of addon.

2Extensions
4Themes
8Locale
16Plugin
32Multiple Item Package

Examples

<em:type>2</em:type>

{{template.Fx_minversion_inline(1.5)}} This property was added for Firefox 1.5, and is only required for addon types other than Extensions and Themes.

targetApplication

An object specifying an application targeted by this addon. This means that the addon will work with the application identified by the id property (<em:id>) specified (for a comprehensive list of application IDs see Valid application versions for add-on developers), from the minimum version (<em:minVersion>) up to and including the maximum version (<em:maxVersion>). These version strings are formatted in the same fashion as the version property and will be compared to the application version; this allows the extension author to specify which versions of Firefox an extension has been tested with.

Note: Firefox 1.0-1.0.6 all have an application version of 1.0. Security and stability updates of Firefox 1.5 have application version 1.5.0.1, 1.5.0.2, etc. Extensions compatible with Firefox or Thunderbird 1.5 should specify a maxVersion of 1.5.0.*, so that they are automatically compatible with security and stability updates.

Extensions compatible with Firefox 2 should specify a maxVersion of 2.0.0.*

The Install Manifest must specify at least one of these objects, and may specify more if the addon targets multiple applications that support the Addon Manager (e.g. Firefox and Thunderbird)

Examples

<em:targetApplication>
 <Description>
  <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id> Firefox
  <em:minVersion>1.5</em:minVersion>
  <em:maxVersion>2.0.0.*</em:maxVersion>
 </Description>
</em:targetApplication>

name

The name of the addon- intended for display in the UI.

Examples

<em:name>My Extension</em:name>

Optional Property Reference

You may need to supply these properties, depending on the capabilities of your add-on.

localized

Allows you to localize the add-on's name, description, contributors and other metadata. The localized description must specify at least one em:locale which indicates which locales to use this information for.

Examples

This declares a set of add-on metadata to be displayed when the application is running in the de-DE locale.

<em:localized>
  <Description>
    <em:locale>de-DE</em:locale>
    <em:name>Tab Sidebar</em:name>
    <em:description>Zeigt in einer Sidebar Vorschaubilder der Inhalte aller offenen Tabs an.</em:description>
  </Description>
</em:localized>

The following properties which are described elsewhere in this page can be included in the localized property:

  • name
  • description
  • creator
  • homepageURL
  • developer
  • translator
  • contributor

More documentation can be found at Localizing extension descriptions.

{{template.Fx_minversion_inline(3)}} This property was added for Firefox 3.

description

A short description of the add-on - intended for display in the user interface. This description should fit on one short line of text.

Examples

<em:description>Advanced foo tools.</em:description>

creator

The name of the creator/principal developer - intended for display in the user interface.

Examples

<em:creator>John Doe</em:creator>

or

<em:creator>CoolExtension Team</em:creator>

developer

The name(s) of co-developers. You may specify more than one of this value to specify multiple developers. {{template.Fx_minversion_inline(2)}}

Examples

<em:developer>Jane Doe</em:developer>
<em:developer>Koos van der Merwe</em:developer>

translator

The name(s) of translators. You may specify more than one of this value to specify multiple translators. {{template.Fx_minversion_inline(2)}}

Examples

<em:translator>Janez Novak</em:translator>
<em:translator>Kari Nordmann</em:translator>

contributor

The name(s) of additional contributors. You may specify more than one of this value to specify multiple contributors.

Examples

<em:contributor>John Doe</em:contributor>

<em:contributor>John Doe</em:contributor>
<em:contributor>Jane Doe</em:contributor>
<em:contributor>Elvis Presley</em:contributor>

homepageURL

A link to the addon's home page - intended for display in the user interface.

Examples

<em:homepageURL>http://www.foo.com/</em:homepageURL>

updateURL

A link to a custom Update Manifest file that specifies available updates to the addon. The format is described below. If enabled, the addon manager periodically checks with this Manifest file to determine if newer versions are available.

Warning: It is strongly recommended that the updateURL be an HTTPS (secure) link. Non-secure update URLs can be hijacked by a malicious update.rdf file, enabling malware to infiltrate the user's computer. Alternatively, you could host your extension on AMO and leave out the updateURL completely. This provides secure updates automatically.

Your server must send this file as text/rdf or the update checker will not work. text/xml also seems to work (projects on mozdev.org)

The addon manager will substitute the following values into this URL in case you wish to generate the response RDF dynamically, such as using PHP or CGI:

%REQ_VERSION%The version of the request. Currently 1
%ITEM_ID%The id of the addon being updated
%ITEM_VERSION%The version of the addon being updated
%ITEM_MAXAPPVERSION%The maxVersion of the targetApplication object corresponding to the current application for the addon being updated.
%APP_ID%The id of the current application
%APP_VERSION%The version of the current application
%APP_OS%The value of OS_TARGET from the Firefox build system, identifying the operating system being used. {{template.Fx_minversion_inline(1.5)}}
%APP_ABI%The value of the TARGET_XPCOM_ABI value from the Firefox build system, identifying the compiler/architecture combination used to compile the current application. {{template.Fx_minversion_inline(1.5)}}

Examples

<em:updateURL>http://www.foo.com/update.cgi?id=%ITEM_ID%&amp;version=%ITEM_VERSION%</em:updateURL>
<em:updateURL>http://www.foo.com/extension/windows.rdf</em:updateURL>

For addons hosted on addons.mozilla.org: You may not specify an updateURL property. By default, Mozilla applications using the Addon Manager (such as Firefox and Thunderbird) will send update requests to addons.mozilla.org using the default web service. Every time you upload a new version of your addon or change its compatibility parameters through the author interface, your update manifest will be generated automatically.

Format of the Update Manifest: The Update Manifest is a RDF/XML datasource. For examples of an update manifest, see Extension Versioning, Update and Compatibility and Enabling Extension Updates (external).

optionsURL

The chrome:// URL of the extension's options dialog box. This is only useful to extensions. If this property is specified, when the extension is selected in the Extensions list, the Options button is enabled and will show this.

Examples

<em:optionsURL>chrome://myext/content/options.xul</em:optionsURL>

aboutURL

The chrome:// URL of the extension's about dialog box. This is only useful to extensions. If this property is specified, when the extension is selected in the Extensions list, the About... link in the extension's context menu will show this dialog, rather than the default.

Examples

<em:aboutURL>chrome://myext/content/about.xul</em:aboutURL>

iconURL

A chrome:// URL to a 32x32 icon to display in the addons list. If this property is not specified, a default icon is used.

<em:iconURL>chrome://myext/skin/icon.png</em:iconURL>

Note: For the above example to work you will also have to add a skin package line to your chrome.manifest file. See Chrome Registration#skin. Alternatively you can place your icon in the directory specified in your content package line.

hidden

A boolean value that when true makes the add-on not show up in the add-ons list, provided the add-on is installed in a {{template.Anch("restricted access area")}} (so it does not work for add-ons installed in the profile). This is for bundling integration hooks to larger applications where having an entry in the Extensions list does not make sense.

Examples

<em:hidden>true</em:hidden>

targetPlatform

A string specifying a platform that the addon supports. It contains either the value of OS_TARGET alone or combined with TARGET_XPCOM_ABI, separated by an underscore (_).

OS_TARGET is typically the output of the 'uname -s' command on the target platform, e.g.:

  • WINNT for Windows NT, 2000, XP and later
  • Linux for all Linux versions
  • Darwin for all MacOS X versions
  • SunOS for all Solaris versions

You can specify multiple targetPlatform properties per manifest. If any value matches the application's build parameters, it will be installed; if not, the user will get an appropriate error message.

Examples

<em:targetPlatform>WINNT_x86-msvc</em:targetPlatform>

<em:targetPlatform>Linux</em:targetPlatform>

<em:targetPlatform>Darwin_ppc-gcc3</em:targetPlatform>

<em:targetPlatform>SunOS_sparc-sunc</em:targetPlatform>

Usually, you would use only the OS part for themes or for extensions that are not fully cross-platform. For extensions including binary (compiled) components, you should never use the OS alone, but include the ABI (s) that you compiled the components with. If you want to include multiple versions of the components, you should also use Platform-specific Subdirectories.

Notes

  • In the same manifest file, you could even mix values with and without ABI. If a value for the application's OS is encountered that requires any specific ABI, the ABI is considered important for that OS and the application will refuse to install the addon if it does not find a matching OS/ABI combination. This means that if all of the above examples would occur in one manifest, the addon will install on any Linux build of the application, regardless of its ABI, but not on a Windows Cygwin build.
  • There may be builds of Firefox and Thunderbird which do not "know" their ABI (most likely ports to rare platforms, or non-official builds). These builds will refuse to install any addon that requires a specific ABI for their platform.

{{template.Fx_minversion_inline(1.5)}} This property was added for Firefox/Thunderbird 1.5. Previous versions of these applications will ignore the restrictions and install the addon regardless of the platform.

requires

This tag has a similar syntax to the <em:targetApplication> tag. If the addon specified by the <em:id> tag is not installed or has an incompatible version, the extension manager will disable your extension and show the message "Requires additional items". You can add as many <em:requires> tags as you like. Your extension will be disabled if any of the specified requirements fail.

Example

<em:requires>
   <Description>
     <!-- Lightning -->
     <em:id>{e2fda1a4-762b-4020-b5ad-a41df1933103}</em:id>
     <em:minVersion>0.5pre</em:minVersion>
     <em:maxVersion>0.5pre</em:maxVersion>
   </Description>
 </em:requires>

Notes

  • Currently, only <em:id>, <em:minVersion>, <em:maxVersion> are parsed inside the <em:requires> tag.
  • It is not currently possible to add dependencies that are specific to a <em:targetApplication>. See {{mediawiki.interwiki('wikimo', 'Extension_Manager:Extension_Dependencies', 'wikimo:Extension Manager:Extension Dependencies')}} for more details.

{{template.Fx_minversion_inline(2)}} This property was added for Firefox/Thunderbird 2. Previous versions of these applications will ignore the restrictions and install the addon regardless of the requirements.

Obsolete Property Reference

These properties were required in older versions of the Addon Manager, but have been replaced with newer and better mechanisms.

file

Firefox 1.0 This property pointed to a chrome .jar file that contains chrome packages that require registration with the Chrome Registry.

The <em:file> property has a complex object value. The uri of the value is urn:mozilla:extension:file:jarFile.jar where jarFile.jar is the name of the jar file that contains the chrome package's files. This could also be the name of a directory that contains the chrome package's files, un-jarred (e.g. urn:mozilla:extension:file:directory). In either case, the referenced chrome package file(s) must be placed in the chrome subdirectory of the XPI's top level.

This object has a package property (with a path within the jar file or directory that leads to the location where the contents.rdf file responsible for registering that package is located), a locale property (ditto, but to register the locale) and a skin property (ditto, but to register the theme material).

In extensions for Firefox 1.5, this property is no longer necessary: the chrome.manifest at the top level of the XPI is used to locate chrome to register. If there is no chrome.manifest, this property is still read by the Addon Manager and a chrome.manifest is generated from old-style contents.rdf.

Examples

<em:file>
 <Description about="urn:mozilla:extension:file:myext.jar">
  <em:package>content/myext/</em:package>
  <em:locale>locale/en-US/myext/</em:locale>
  <em:skin>skin/classic/myext/<em:skin>
 </Description>
</em:file>

An Install Manifest may specify multiple file properties, one for each jar file or subdirectory that contains chrome to register.

Glossary

restricted access area

A restricted access area is an install location that could be restricted on a restricted-access account, regardless of whether or not the location is restricted with the current user privileges (see {{template.Source("toolkit/mozapps/extensions/public/nsIExtensionManager.idl#80", "nsIInstallLocation::restricted")}}). Currently, the ($APPDIR)/extensions folder and the registry install location under HKEY_LOCAL_MACHINE (see Adding Extensions using the Windows Registry for details) are restricted.

The ($PROFILE)/extensions and HKEY_CURRENT_USER install locations, on the other hand, are not restricted.


{{ wiki.languages( { "es": "es/Instalar_el_manifest", "fr": "fr/Manifestes_d\'installation", "ja": "ja/Install_Manifests", "pl": "pl/Manifesty_Instalacji" } ) }}

Revision Source

<p>
</p>
<h3 name="Introduction"> Introduction </h3>
<p>An Install Manifest is the file an Addon Manager-enabled XUL application uses to determine information about an addon as it is being installed. It contains metadata identifying the addon, providing information about who created it, where more information can be found about it, which versions of what applications it is compatible with, how it should be updated, and so on.
</p><p>The format of the Install Manifest is RDF/XML.
</p><p>The file must be called <code>install.rdf</code> and live at the top level of an addon's XPI file.
</p>
<h3 name="Layout"> Layout </h3>
<p>The basic layout of an Install Manifest is like so:
</p>
<pre class="eval">&lt;?xml version="1.0"?&gt;

&lt;RDF xmlns="<span class="plain">http://www.w3.org/1999/02/22-rdf-syntax-ns#</span>"
     xmlns:em="<span class="plain">http://www.mozilla.org/2004/em-rdf#</span>"&gt;
  &lt;Description about="urn:mozilla:install-manifest"&gt;
    &lt;!-- properties --&gt;
  &lt;/Description&gt;
&lt;/RDF&gt;
</pre>
<p>Some properties are required, some are optional. Some have simple string values, some are complex resources.
</p>
<h3 name="Required_Property_Reference"> Required Property Reference </h3>
<p>Your Install Manifest must specify these properties correctly otherwise your addon may not install. 
</p>
<h4 name="id"> id </h4>
<p>The id of the extension, which is a:
</p>
<ul><li> GUID (generate using guidgen on Windows, uuidgen on Linux and makeuuid on Solaris) (Firefox 1.0)
</li><li> {{template.Fx_minversion_inline(1.5)}} A string formatted like so: <code>extensionname@organization.tld</code>
</li></ul>
<p>The latter format is significantly easier to generate and manipulate. Firefox 1.5 has checking to ensure that your id falls into one format or the other and will refuse to install addons that have malformed ids. 
</p><p><b>Examples</b>
</p>
<pre class="eval">&lt;em:id&gt;myextension@mysite.com&lt;/em:id&gt;

&lt;em:id&gt;{daf44bf7-a45e-4450-979c-91cf07434c3d}&lt;/em:id&gt;
</pre>
<h4 name="version"> version </h4>
<p>A version string identifying the version of the addon being supplied.
</p><p>For Firefox/Thundebird 1.0, the format must conform to the rules specified in <a href="en/Extension_Versioning%2c_Update_and_Compatibility">Extension Versioning, Update and Compatibility</a>. For Firefox/Thundebird 1.5, see <a href="en/Toolkit_version_format">Toolkit version format</a>.
</p><p><b>Examples</b>
</p>
<pre class="eval">&lt;em:version&gt;2.0&lt;/em:version&gt;

&lt;em:version&gt;1.0.2&lt;/em:version&gt;

&lt;em:version&gt;0.4.1.2005090112&lt;/em:version&gt;

</pre>
<p><b>Firefox 1.5 / XULRunner 1.8</b> - addons that do not use a valid version format will not be installed. The version format is different from, although backwards-compatible with, 1.0's.
</p><p><b>For addons hosted on addons.mozilla.org</b> - Mozilla's update website may repackage your addon and correct or reject malformed version strings.
</p>
<h4 name="type"> type </h4>
<p>An integer value representing the type of addon. 
</p>
<table>
 <tbody><tr><td>2</td><td>Extensions</td></tr>
 <tr><td>4</td><td>Themes</td></tr>
 <tr><td>8</td><td>Locale</td></tr>
 <tr><td>16</td><td>Plugin</td></tr>
 <tr><td>32</td><td><a href="en/Multiple_Item_Packaging">Multiple Item Package</a></td></tr>
</tbody></table>
<p><b>Examples</b>
</p>
<pre class="eval">&lt;em:type&gt;2&lt;/em:type&gt;
</pre>
<p>{{template.Fx_minversion_inline(1.5)}} This property was added for Firefox 1.5, and is only required for addon types other than Extensions and Themes.
</p>
<h4 name="targetApplication"> targetApplication </h4>
<p>An object specifying an application targeted by this addon. This means that the addon will work with the application identified by the id property (<code>&lt;em:id&gt;</code>) specified (for a comprehensive list of application IDs see <a class="external" href="https://addons.mozilla.org/en-US/firefox/pages/appversions">Valid application versions for add-on developers</a>), from the minimum version (<code>&lt;em:minVersion&gt;</code>) up to and including the maximum version (<code>&lt;em:maxVersion&gt;</code>). These version strings are formatted in the same fashion as the <a href="#version"><code>version</code> property</a> and will be compared to the application version; this allows the extension author to specify which versions of Firefox an extension has been tested with.
</p><p>Note: Firefox 1.0-1.0.6 all have an application version of <code>1.0</code>. Security and stability updates of Firefox 1.5 have application version 1.5.0.1, 1.5.0.2, etc. Extensions compatible with Firefox or Thunderbird 1.5 should specify a maxVersion of 1.5.0.*, so that they are automatically compatible with security and stability updates.
</p><p>Extensions compatible with Firefox 2 should specify a <code>maxVersion</code> of <code>2.0.0.*</code>
</p><p>The Install Manifest must specify at least one of these objects, and may specify more if the addon targets multiple applications that support the Addon Manager (e.g. Firefox and Thunderbird)
</p><p><b>Examples</b>
</p>
<pre class="eval">&lt;em:targetApplication&gt;
 &lt;Description&gt;
  &lt;em:id&gt;{ec8030f7-c20a-464f-9b0e-13a3a9e97384}&lt;/em:id&gt; <span class="comment">Firefox</span>
  &lt;em:minVersion&gt;1.5&lt;/em:minVersion&gt;
  &lt;em:maxVersion&gt;2.0.0.*&lt;/em:maxVersion&gt;
 &lt;/Description&gt;
&lt;/em:targetApplication&gt;
</pre>
<h4 name="name"> name </h4>
<p>The name of the addon- intended for display in the UI.
</p><p><b> Examples </b>
</p>
<pre class="eval">&lt;em:name&gt;My Extension&lt;/em:name&gt;
</pre>
<h3 name="Optional_Property_Reference"> Optional Property Reference </h3>
<p>You may need to supply these properties, depending on the capabilities of your add-on.
</p>
<h4 name="localized"> localized </h4>
<p>Allows you to localize the add-on's name, description, contributors and other metadata. The localized description must specify at least one <code>em:locale</code> which indicates which locales to use this information for.
</p><p><b>Examples</b>
</p><p>This declares a set of add-on metadata to be displayed when the application is running in the de-DE locale.
</p>
<pre>&lt;em:localized&gt;
  &lt;Description&gt;
    &lt;em:locale&gt;de-DE&lt;/em:locale&gt;
    &lt;em:name&gt;Tab Sidebar&lt;/em:name&gt;
    &lt;em:description&gt;Zeigt in einer Sidebar Vorschaubilder der Inhalte aller offenen Tabs an.&lt;/em:description&gt;
  &lt;/Description&gt;
&lt;/em:localized&gt;
</pre>
<p>The following properties which are described elsewhere in this page can be included in the localized property:
</p>
<ul><li> name
</li><li> description
</li><li> creator
</li><li> homepageURL
</li><li> developer
</li><li> translator
</li><li> contributor
</li></ul>
<p>More documentation can be found at <a href="en/Localizing_extension_descriptions">Localizing extension descriptions</a>.
</p><p>{{template.Fx_minversion_inline(3)}} This property was added for Firefox 3.
</p>
<h4 name="description"> description </h4>
<p>A short description of the add-on - intended for display in the user interface. This description should fit on one short line of text.
</p><p><b>Examples</b>
</p>
<pre class="eval">&lt;em:description&gt;Advanced foo tools.&lt;/em:description&gt;
</pre>
<h4 name="creator"> creator </h4>
<p>The name of the creator/principal developer - intended for display in the user interface.
</p><p><b>Examples</b>
</p>
<pre class="eval">&lt;em:creator&gt;John Doe&lt;/em:creator&gt;
</pre>
<p>or
</p>
<pre class="eval">&lt;em:creator&gt;CoolExtension Team&lt;/em:creator&gt;
</pre>
<h4 name="developer"> developer </h4>
<p>The name(s) of co-developers. You may specify more than one of this value to specify multiple developers.
{{template.Fx_minversion_inline(2)}}
</p><p><b>Examples</b>
</p>
<pre class="eval">&lt;em:developer&gt;Jane Doe&lt;/em:developer&gt;
&lt;em:developer&gt;Koos van der Merwe&lt;/em:developer&gt;
</pre>
<h4 name="translator"> translator </h4>
<p>The name(s) of translators. You may specify more than one of this value to specify multiple translators. 
{{template.Fx_minversion_inline(2)}}
</p><p><b>Examples</b>
</p>
<pre class="eval">&lt;em:translator&gt;Janez Novak&lt;/em:translator&gt;
&lt;em:translator&gt;Kari Nordmann&lt;/em:translator&gt;
</pre>
<h4 name="contributor"> contributor </h4>
<p>The name(s) of additional contributors. You may specify more than one of this value to specify multiple contributors. 
</p><p><b>Examples</b>
</p>
<pre class="eval">&lt;em:contributor&gt;John Doe&lt;/em:contributor&gt;

&lt;em:contributor&gt;John Doe&lt;/em:contributor&gt;
&lt;em:contributor&gt;Jane Doe&lt;/em:contributor&gt;
&lt;em:contributor&gt;Elvis Presley&lt;/em:contributor&gt;
</pre>
<h4 name="homepageURL"> homepageURL </h4>
<p>A link to the addon's home page - intended for display in the user interface.
</p><p><b>Examples</b>
</p>
<pre class="eval">&lt;em:homepageURL&gt;<span class="plain">http://www.foo.com/</span>&lt;/em:homepageURL&gt;
</pre>
<h4 name="updateURL"> updateURL </h4>
<p>A link to a custom Update Manifest file that specifies available updates to the addon. The format is described below. If enabled, the addon manager periodically checks with this Manifest file to determine if newer versions are available. 
</p>
<div class="warning"><b>Warning:</b> It is strongly recommended that the <code>updateURL</code> be an HTTPS (secure) link.  Non-secure update URLs can be hijacked by a malicious <code>update.rdf</code> file, enabling malware to infiltrate the user's computer.  Alternatively, you could host your extension on <a class="external" href="http://addons.mozilla.org">AMO</a> and leave out the <code>updateURL</code> completely.  This provides secure updates automatically.</div>
<p>Your server must send this file as <code>text/rdf</code> or the update checker will not work. <code>text/xml</code> also seems to work (projects on mozdev.org)
</p><p>The addon manager will substitute the following values into this URL in case you wish to generate the response RDF dynamically, such as using PHP or CGI:
</p>
<table border="1" cellpadding="3" cellspacing="2">
 <tbody><tr><td><code>%REQ_VERSION%</code></td><td>The version of the request. Currently 1</td></tr>
 <tr><td><code>%ITEM_ID%</code></td><td>The <code>id</code> of the addon being updated</td></tr>
 <tr><td><code>%ITEM_VERSION%</code></td><td>The <code>version</code> of the addon being updated</td></tr>
 <tr><td><code>%ITEM_MAXAPPVERSION%</code></td><td>The <code>maxVersion</code> of the <code>targetApplication</code> object corresponding to the current application for the addon being updated.</td></tr>
 <tr><td><code>%APP_ID%</code></td><td>The <code>id</code> of the current application</td></tr>
 <tr><td><code>%APP_VERSION%</code></td><td>The <code>version</code> of the current application</td></tr>
 <tr><td><code>%APP_OS%</code></td><td>The value of <code>OS_TARGET</code> from the Firefox build system, identifying the operating system being used. {{template.Fx_minversion_inline(1.5)}}</td></tr>
 <tr><td><code>%APP_ABI%</code></td><td>The value of the <code>TARGET_XPCOM_ABI</code> value from the Firefox build system, identifying the compiler/architecture combination used to compile the current application. {{template.Fx_minversion_inline(1.5)}}</td></tr>
</tbody></table>
<p><b>Examples</b>
</p>
<pre class="eval">&lt;em:updateURL&gt;<span class="plain">http://www.foo.com/update.cgi?id=%ITEM_ID%&amp;amp;version=%ITEM_VERSION%</span>&lt;/em:updateURL&gt;
&lt;em:updateURL&gt;<span class="plain">http://www.foo.com/extension/windows.rdf</span>&lt;/em:updateURL&gt;
</pre>
<p><b>For addons hosted on addons.mozilla.org:</b> You may not specify an updateURL property. By default, Mozilla applications using the Addon Manager (such as Firefox and Thunderbird) will send update requests to <code>addons.mozilla.org</code> using the default web service. Every time you upload a new version of your addon or change its compatibility parameters through the author interface, your update manifest will be generated automatically.
</p><p><b>Format of the Update Manifest:</b> The Update Manifest is a RDF/XML datasource. For examples of an update manifest, see <a href="en/Extension_Versioning%2c_Update_and_Compatibility#Custom_Update_RDF_Format">Extension Versioning, Update and Compatibility</a> and <a href="en/Enabling_Extension_Updates_(external)">Enabling Extension Updates (external)</a>.
</p>
<h4 name="optionsURL"> optionsURL </h4>
<p>The <code>chrome://</code> URL of the extension's options dialog box. This is only useful to extensions. If this property is specified, when the extension is selected in the Extensions list, the Options button is enabled and will show this.
</p><p><b>Examples</b>
</p>
<pre class="eval">&lt;em:optionsURL&gt;chrome://myext/content/options.xul&lt;/em:optionsURL&gt;
</pre>
<h4 name="aboutURL"> aboutURL </h4>
<p>The <code>chrome://</code> URL of the extension's about dialog box. This is only useful to extensions. If this property is specified, when the extension is selected in the Extensions list, the About... link in the extension's context menu will show this dialog, rather than the default.
</p><p><b>Examples</b>
</p>
<pre class="eval">&lt;em:aboutURL&gt;chrome://myext/content/about.xul&lt;/em:aboutURL&gt;
</pre>
<h4 name="iconURL"> iconURL </h4>
<p>A <code>chrome://</code> URL to a 32x32 icon to display in the addons list. If this property is not specified, a default icon is used. 
</p>
<pre class="eval">&lt;em:iconURL&gt;chrome://myext/skin/icon.png&lt;/em:iconURL&gt;
</pre>
<p>Note: <em>For the above example to work you will also have to add a <code>skin package</code> line to your <code>chrome.manifest</code> file. See <a href="en/Chrome_Registration#skin">Chrome Registration#skin</a>.</em> Alternatively you can place your icon in the directory specified in your <code>content package</code> line.
</p>
<h4 name="hidden"> hidden </h4>
<p>A boolean value that when <code>true</code> makes the add-on not show up in the add-ons list, provided the add-on is installed in a {{template.Anch("restricted access area")}} (so it does not work for add-ons installed in the profile). This is for bundling integration hooks to larger applications where having an entry in the Extensions list does not make sense.
</p><p><b>Examples</b>
</p>
<pre class="eval">&lt;em:hidden&gt;true&lt;/em:hidden&gt;
</pre>
<h4 name="targetPlatform"> targetPlatform </h4>
<p>A string specifying a platform that the addon supports. It contains either the value of OS_TARGET alone or combined with <a href="en/XPCOM_ABI">TARGET_XPCOM_ABI</a>, separated by an underscore (_).
</p><p>OS_TARGET is typically the output of the 'uname -s' command on the target platform, e.g.:
</p>
<ul><li> <code>WINNT</code> for Windows NT, 2000, XP and later
</li><li> <code>Linux</code> for all Linux versions
</li><li> <code>Darwin</code> for all MacOS X versions
</li><li> <code>SunOS</code> for all Solaris versions
</li></ul>
<p>You can specify multiple targetPlatform properties per manifest. If any value matches the application's build parameters, it will be installed; if not, the user will get an appropriate error message.
</p><p><b>Examples</b>
</p>
<pre class="eval">&lt;em:targetPlatform&gt;WINNT_x86-msvc&lt;/em:targetPlatform&gt;

&lt;em:targetPlatform&gt;Linux&lt;/em:targetPlatform&gt;

&lt;em:targetPlatform&gt;Darwin_ppc-gcc3&lt;/em:targetPlatform&gt;

&lt;em:targetPlatform&gt;SunOS_sparc-sunc&lt;/em:targetPlatform&gt;
</pre>
<p>Usually, you would use only the OS part for themes or for extensions that are not fully cross-platform. For extensions including binary (compiled) components, you should never use the OS alone, but include the <a href="en/XPCOM_ABI">ABI (s)</a> that you compiled the components with. If you want to include multiple versions of the components, you should also use <a href="en/Bundles#Platform-specific_Subdirectories">Platform-specific Subdirectories</a>.
</p><p><b>Notes</b>
</p>
<ul><li> In the same manifest file, you could even mix values with and without ABI. If a value for the application's OS is encountered that requires any specific ABI, the ABI is considered important for that OS and the application will refuse to install the addon if it does not find a matching OS/ABI combination. This means that if all of the above examples would occur in one manifest, the addon will install on any Linux build of the application, regardless of its ABI, but not on a Windows Cygwin build.
</li></ul>
<ul><li> There may be builds of Firefox and Thunderbird which do not "know" their ABI (most likely ports to rare platforms, or non-official builds). These builds will refuse to install any addon that requires a specific ABI for their platform.
</li></ul>
<p>{{template.Fx_minversion_inline(1.5)}} This property was added for Firefox/Thunderbird 1.5. Previous versions of these applications will ignore the restrictions and install the addon regardless of the platform.
</p>
<h4 name="requires"> requires </h4>
<p>This tag has a similar syntax to the <code>&lt;em:targetApplication&gt;</code> tag. If the addon specified by the <code>&lt;em:id&gt;</code> tag is not installed or has an incompatible version, the extension manager will disable your extension and show the message "Requires additional items". You can add as many <code>&lt;em:requires&gt;</code> tags as you like. Your extension will be disabled if any of the specified requirements fail.
</p><p><b>Example</b>
</p>
<pre>&lt;em:requires&gt;
   &lt;Description&gt;
     &lt;!-- Lightning --&gt;
     &lt;em:id&gt;{e2fda1a4-762b-4020-b5ad-a41df1933103}&lt;/em:id&gt;
     &lt;em:minVersion&gt;0.5pre&lt;/em:minVersion&gt;
     &lt;em:maxVersion&gt;0.5pre&lt;/em:maxVersion&gt;
   &lt;/Description&gt;
 &lt;/em:requires&gt;
</pre>
<p><b>Notes</b>
</p>
<ul><li> Currently, only <code>&lt;em:id&gt;</code>, <code>&lt;em:minVersion&gt;</code>, <code>&lt;em:maxVersion&gt;</code> are parsed inside the <code>&lt;em:requires&gt;</code> tag.
</li><li> It is not currently possible to add dependencies that are specific to a <code>&lt;em:targetApplication&gt;</code>. See {{mediawiki.interwiki('wikimo', 'Extension_Manager:Extension_Dependencies', 'wikimo:Extension Manager:Extension Dependencies')}} for more details.
</li></ul>
<p>{{template.Fx_minversion_inline(2)}} This property was added for Firefox/Thunderbird 2. Previous versions of these applications will ignore the restrictions and install the addon regardless of the requirements.
</p>
<h3 name="Obsolete_Property_Reference"> Obsolete Property Reference </h3>
<p>These properties were required in older versions of the Addon Manager, but have been replaced with newer and better mechanisms.
</p>
<h4 name="file"> file </h4>
<p><b>Firefox 1.0</b> This property pointed to a chrome <code>.jar</code> file that contains chrome packages that require registration with the Chrome Registry.
</p><p>The <code>&lt;em:file&gt;</code> property has a complex object value. The uri of the value is <code>urn:mozilla:extension:file:jarFile.jar</code> where <code>jarFile.jar</code> is the name of the jar file that contains the chrome package's files. This could also be the name of a directory that contains the chrome package's files, un-jarred (e.g. <code>urn:mozilla:extension:file:directory</code>). In either case, the referenced chrome package file(s) must be placed in the <code>chrome</code> subdirectory of the XPI's top level.
</p><p>This object has a <code>package</code> property (with a path within the jar file or directory that leads to the location where the <code>contents.rdf</code> file responsible for registering that package is located), a <code>locale</code> property (ditto, but to register the locale) and a <code>skin</code> property (ditto, but to register the theme material).
</p><p>In extensions for Firefox 1.5, this property is no longer necessary: the <code><a href="en/Chrome_Registration">chrome.manifest</a></code> at the top level of the XPI is used to locate chrome to register. If there is no chrome.manifest, this property is still read by the Addon Manager and a chrome.manifest is generated from old-style contents.rdf.
</p><p><b>Examples</b>
</p>
<pre class="eval">&lt;em:file&gt;
 &lt;Description about="urn:mozilla:extension:file:myext.jar"&gt;
  &lt;em:package&gt;content/myext/&lt;/em:package&gt;
  &lt;em:locale&gt;locale/en-US/myext/&lt;/em:locale&gt;
  &lt;em:skin&gt;skin/classic/myext/&lt;em:skin&gt;
 &lt;/Description&gt;
&lt;/em:file&gt;
</pre>
<p>An Install Manifest may specify multiple <code>file</code> properties, one for each jar file or subdirectory that contains chrome to register.
</p>
<h3 name="Glossary"> Glossary </h3>
<h3 name="restricted_access_area"> restricted access area </h3>
<p>A <i>restricted access area</i> is an install location that could be restricted on a restricted-access account, regardless of whether or not the location is restricted with the current user privileges (see {{template.Source("toolkit/mozapps/extensions/public/nsIExtensionManager.idl#80", "nsIInstallLocation::restricted")}}). Currently, the <code>($APPDIR)/extensions</code> folder and the registry install location under <code>HKEY_LOCAL_MACHINE</code> (see <a href="en/Adding_Extensions_using_the_Windows_Registry">Adding Extensions using the Windows Registry</a> for details) are restricted.
</p><p>The <code>($PROFILE)/extensions</code> and <code>HKEY_CURRENT_USER</code> install locations, on the other hand, are not restricted.
</p><p><br>
</p>
<div class="noinclude">
</div>
{{ wiki.languages( { "es": "es/Instalar_el_manifest", "fr": "fr/Manifestes_d\'installation", "ja": "ja/Install_Manifests", "pl": "pl/Manifesty_Instalacji" } ) }}
Revert to this revision