关于Manifest文件

  • 版本网址缩略名: XUL_教程/1-4_关于Manifest文件
  • 版本标题: 关于Manifest文件
  • 版本 id: 272991
  • 创建于:
  • 创建者: nemo21cn
  • 是否是当前版本?
  • 评论 no wording changes; page display name changed to '关于Manifest文件'

修订内容

{{ PreviousNext("XUL 教程:The Chrome URL", "XUL 教程:Creating a Window") }}


在这部分内容里,我们将具体描述怎样将chrome和XUL文件打包成一个文件并根据内容创建一个manifest文件。

包(Packages)

包是将一些定义用户界面及功能的XUL文件和脚本文件打包而成的。包可以安装在Mozilla中,并用chrome URLs引用。一个包可以包括任意数量的文件,并分别安装在不同的子目录中。包可以存储在文件目录或JAR文件中。

声明(Manifest)文件

声明文件描述包和实际存储位置之间的关系。当Mozilla程序启动时,会自动检查安装了哪些包,并在chrome目录下寻找声明文件(一般在<ApplicationDirectory>/chrome下)。也就是说,如果要安装一个新的包,只要在Mozilla程序的chrome或者用户指定的chrome目录下增加一个新的声明文件就可以了。由于Mozilla程序的目录可能要求较高的权限,后一种方式更常用。

如果只想在Firefox下写些XUL的测试代码,你可以按以下步骤简单地实现:

  1. 随便在哪里创建一个新的目录。比如在Windows下创建一个C:\testfiles
  2. 在chrome目录下创建一个名为 test.manifest 的 ASCII1 文件。只要后缀为 .manifest 文件名是什么没关系。 ( 1. doesn't work with UTF-8 with BOM.)
  3. 在文件中增加以下行:
 content tests file:///C:/testfiles/

该行中的文件路径指向刚才创建的目录。如果你不清楚文件路径怎么写,可以在浏览器中打开该目录,然后从地址栏将URL直接拷贝过去。

好了!现在,你只要在新的目录中增加XUL文件,你就可以通过 chrome://tests/content/tests.xul<filename>找到他们。为了让变化生效,你需要重启浏览器。如果文件无法装载,请检查文件路径是否正确。

content包在声明文件中的基本语法是:

'content <packagename> <filepath>'

第一个字段 'content' 表明是内容包。主题使用 'skin' ,本地化用 'locale'. The packagename is the example above is 'tests', which means that the first field in the chrome URL is 'tests' as in chrome://tests/content/sample.xul. If the package name was 'browser', the chrome URL would be chrome://browser/content/browser.xul. The final field is the path where the files are located. This can be either a local file path using a file URL or a JAR archive using a jar URL, which will be described in a moment. You can specify multiple packages by including another line in the manifest file.

Firefox的 browser.manifest 长的像这样:

content branding jar:browser.jar!/content/branding/ xpcnativewrappers=yes
content browser jar:browser.jar!/content/browser/ xpcnativewrappers=yes
overlay chrome://global/content/viewSource.xul chrome://browser/content/viewSourceOverlay.xul
overlay chrome://global/content/viewPartialSource.xul chrome://browser/content/viewSourceOverlay.xul
overlay chrome://browser/content/pageInfo.xul chrome://pippki/content/PageInfoOverlay.xul

Two packages are listed here, 'branding' and 'browser'. Three overlays are also specified, which allow content from different packages to combine together. Extensions will make the most use of overlays, since they merge their UI with the browser UI.

The file paths for the branding and browser packages use jar URLs as the content is packaged up into an archive. A JAR archive can be created with a ZIP utility. For a JAR file located in the chrome directory, the syntax is fairly simple:

jar:<filename.jar>!/<path_in_archive>

For the browser package, the archive is browser.jar, located alongside the manifest file in the chrome directory. The path 'content/browser' specifies the path inside the archive where the XUL files are located. You won't need to specify a path if you don't have any directories in the archive. In this case, there is, since the files for the branding package are stored in a different path in the same archive.

For the 'tests' package created above, the files are not packaged into an archive, so a direct file path is used instead. This is good for development since you don't have to package up all the files every time you change them. However, when distributing an application or extension, you will want to package them into an archive to avoid having to install lots of smaller files.

The xpcnativewrappers=yes part at the end of the manifest line is a flag that may optionally be used. In JavaScript, it is possible for a web page to override built-in functions with their own code. If the xpcnativewrappers flag is specified, it indicates that scripts running in a privileged context don't call these overriden versions, but the original built-in versions instead. Otherwise, if an extension attempted to call the modified versions, it would likely not work properly, or worse, create a security hole. This flag was added to prevent this problem and should always be used for newer extensions, but is left out for older extensions that might not be compatible with the change. For more information about this feature, see XPCNativeWrapper.

Themes and Locales
Edit section

The themes and locales, the syntax is similar as for content packages, but you also need to specify the content package you are providing a theme or locale for. For example:

skin browser classic/1.0 jar:classic.jar!/skin/classic/browser/
locale browser en-US jar:en-US.jar!/locale/browser/

For these, the extra field has been added to indicate that the skin and locale applies to the browser. The skin name is 'classic/1.0'. In this case, a version number is being used as part of the theme name, but that is optional if you are making your own theme. Mozilla doesn't handle the version number in a special way; the version number is just part of the theme name. The locale is 'en-US'. The chrome URLs that these would map to would be chrome://browser/skin/browser.css and chrome://browser/locale/browser.dtd. If you were creating your own theme or locale for the browser, all you need to do is create a manifest file with one of these two lines in it, modified to suit your theme or locale.

For more information about Themes, see Themes. For more information about Locales, see Localization.

Our example find files dialog
Edit section

Let's create a manifest file for the find files dialog we'll be creating. You can combine all of the three types into a single file if you wish. This may be done when creating an extension such that all of the parts are in one file. We will do this for the find files dialog. Create a file findfile.manifest in the chrome directory. Add the following to the file:

content findfile file:///findfile/content/
skin findfile classic/1.0 file:///findfile/skin/
locale findfile en-US file:///findfile/locale/

Create the new directories listed above. It doesn't matter where the directories are created, but the file paths in the manifest file should point to the directories. Naturally, you will want to use directory paths suitable for your system. If we were distributing the package, we would want to package them up into a JAR file, and modify the paths. In this case, we are just creating to demonstrate a manifest file and to prepare directories for examples which will see in the later sections.

Note how the second field of the skin and locale lines specifies 'findfile'. This means that the skin and locale modify the findfile package, which was specified on the first line.The three paths above specify subdirectories for each part. You will want to create these subdirectories to keep each part's files separate.

 

Installing a Package
Edit section

For an application to be installed, you will need to create an installer for it, or include it as part of another application. The method used depends on what kind of application you are creating. For extensions, you will need to create an install file install.rdf which describes what will be installed, the author of the extension and which versions of the browser or other applications it is compatible with. A specific directory structure is needed as well since extensions are limited in where the files may be installed to. An extension is packaged up into an XPI file. XPI is short for XPInstall and is used by Mozilla to install components. Like a JAR file, an XPI file is just a ZIP file with a different extension, so you can create and view XPI files with a ZIP utility.

Firefox's extension manager handles installing extensions packaged into XPI files automatically. It is recommended to upload extensions to the Mozilla Add-ons site, where users can locate them for installation. While they may be installed from any site, other sites are not configured to allow installations by default.

It is also possible to use a install script written in JavaScript to install files. This allows you to copy files to any location and perform other file management tasks. However, applications installed with a script will not be listed in the extension manager and there is no automated method to uninstall them. For this reason, the install scripts are not used often.

For standalone applications, they can be packaged up using XULRunner. This allows a separate executable file, and the application may be distributed independently of a browser.

For more information about creating extensions, see Extensions. For more information about XULRunner, see XULRunner.

Older Applications
Edit section

If you are creating applications for older versions of Mozilla software, that is, before Firefox 1.5 or Mozilla 1.8, the process is a bit more involved. The following describes how to set up a package for earlier versions. This section may be skipped if you are writing new extensions or XUL applications.

Note: This older process does also apply to the new SeaMonkey 1.0 though. The codebase there has not yet adopted the "Manifest" format.
  1. Create a directory somewhere on your disk. Many people put this as a subdirectory inside Mozilla's chrome directory, but this isn't necessary. The directory could be anywhere and on any disk. Put your XUL files in this directory.
  2. Create a file called contents.rdf and place it in this directory. Copy the text in the box below into the new contents.rdf file. This file is used to identify the application id, its name, author, version and so on.
  3. <?xml version="1.0"?>
    
    <RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:chrome="http://www.mozilla.org/rdf/chrome#">
    
      <RDF:Seq about="urn:mozilla:package:root">
        <RDF:li resource="urn:mozilla:package:myapplication"/>
      </RDF:Seq>
    
      <RDF:Description about="urn:mozilla:package:myapplication"
              chrome:displayName="Application Title"
              chrome:author="Author Name"
              chrome:name="myapplication"
              chrome:extension="true"/>
    
    </RDF:RDF>
    
  4. Change the highlighted parts of the file above to your own information. The red text 'myapplication' should be the ID of your application. You make this up, but typically, the ID is similar to your application's name. Replace the blue highlighted text above with your application's title and author.
  5. If the 'chrome:extension' field is true, the application is a Mozilla Firefox Extension and it will show up in the Extensions window of the browser. If false, it will not appear.
  6. Save the contents.rdf and make sure it is in the directory you created in step 1.
  7. Open the file <mozilla-directory>/chrome/installed-chrome.txt, where <mozilla-directory> is the directory where Mozilla is installed. Exit Mozilla before you do this.
  8. Next, you are going to register the new application with Mozilla so it will know where to find it. Add a line at the end of installed-chrome.txt pointing to the new directory you created in step 1. Change the highlighted text to the file URL below of the directory. Make sure that it URL ends with a slash and that you press enter at the end of the line. If you aren't sure what the URL is, open the directory created in step 1 into a Mozilla browser and copy the URL from the location field. Note that the reference should always be a directory, not a file.
  9. content,install,url,file:///main/app/
    
  10. Delete the file <mozilla-directory>/chrome/chrome.rdf.
  11. Start Mozilla. You should be able to view any XUL files you put into the directory using a URL of the form: chrome://applicationid/content/file.xul where file.xul is the filename. Your main XUL file should be applicationid.xul which you can load using the shortcut URL chrome://applicationid/content/.

If you are creating skin and/or locale portions, repeat the steps above, except that the format of the contents.rdf file is slightly different. Look at the contents.rdf files in other applications for details.

Troubleshooting
Edit section

Creating a chrome package can often be tricky and it is difficult to diagnose problems. Here are a few tips in case you get stuck.

  • Open the file <mozilla-directory>/chrome/chrome.rdf. You should find references to your application ID in there. If not, something is wrong with registration. If it is there, you are probably using the wrong chrome URL when you load the file.
  • Try deleting the <mozilla-directory>/chrome/chrome.rdf file. It will get regenerated. Also delete the entire <mozilla-directory>/chrome/overlayinfo/ directory if you are using overlays.
  • Make sure that the URL in the line you added to installed-chrome.txt ends with a slash and the file itself ends with a blank line.
  • On Windows, file URLs are of the form file:///C|/files/app/, where C is the drive letter.
  • Make sure the contents.rdf file is in the right directory and is well-formed. Open the contents.rdf file in Mozilla to see if it parses as well-formed XML. If not, you will see an error on a yellow background.
  • If you are using a debug build of Mozilla, some info will be printed to the terminal when starting up indicating what chrome applications are being checked. Check if your application is listed.
  • The error message "XML Parsing Error: undefined entity" in your XUL file can be caused by an error in the manifest or in the jar file referenced by the manifest. For example, in <!DOCTYPE window SYSTEM "chrome://fireclipse/locale/fireclipse.dtd"> the dtd file must exist and its directory must be correctly addressed in the "locale" manifest or XML parsing will fail.

For more information about manifest files, see Chrome Registration.

In the next section, we will start looking into the XUL language.

修订版来源

<p>{{ PreviousNext("XUL 教程:The Chrome URL", "XUL 教程:Creating a Window") }}</p>
<p><br>
在这部分内容里,我们将具体描述怎样将chrome和XUL文件打包成一个文件并根据内容创建一个manifest文件。</p>
<h3 name="Packages">包(Packages)</h3>
<p>包是将一些定义用户界面及功能的XUL文件和脚本文件打包而成的。包可以安装在Mozilla中,并用chrome URLs引用。一个包可以包括任意数量的文件,并分别安装在不同的子目录中。包可以存储在文件目录或JAR文件中。</p>
<h3 name="Packages">声明(Manifest)文件</h3>
<p>声明文件描述包和实际存储位置之间的关系。当Mozilla程序启动时,会自动检查安装了哪些包,并在chrome目录下寻找声明文件(一般在<a href="../../../../en/Runtime_Directories#Firefox" rel="internal">&lt;ApplicationDirectory&gt;</a>/chrome下)。也就是说,如果要安装一个新的包,只要在Mozilla程序的chrome或者用户指定的chrome目录下增加一个新的声明文件就可以了。由于Mozilla程序的目录可能要求较高的权限,后一种方式更常用。</p>
<p>如果只想在Firefox下写些XUL的测试代码,你可以按以下步骤简单地实现:</p>
<ol> <li>随便在哪里创建一个新的目录。比如在Windows下创建一个C:\testfiles</li> <li>在chrome目录下创建一个名为 test.manifest 的 <strong>ASCII</strong><sup>1</sup> 文件。只要后缀为 .manifest 文件名是什么没关系。 <sub>( 1. doesn't work with UTF-8 with BOM.) </sub></li> <li>在文件中增加以下行:</li>
</ol>
<pre class="eval"> content tests <a class=" external" href="file:///C:/testfiles/" rel="freelink">file:///C:/testfiles/</a>
</pre>
<p>该行中的文件路径指向刚才创建的目录。如果你不清楚文件路径怎么写,可以在浏览器中打开该目录,然后从地址栏将URL直接拷贝过去。</p>
<p>好了!现在,你只要在新的目录中增加XUL文件,你就可以通过 <a class=" external" href="chrome://tests/content/tests.xul" rel="freelink">chrome://tests/content/tests.xul</a>&lt;filename&gt;找到他们。为了让变化生效,你需要重启浏览器。如果文件无法装载,请检查文件路径是否正确。</p>
<p>content包在声明文件中的基本语法是:</p>
<p>'content &lt;packagename&gt; &lt;filepath&gt;'</p>
<p>第一个字段 'content' 表明是内容包。主题使用 'skin' ,本地化用 'locale'. The packagename is the example above is 'tests', which means that the first field in the chrome URL is 'tests' as in <a class=" external" href="chrome://tests/content/sample.xul" rel="freelink">chrome://tests/content/sample.xul</a>. If the package name was 'browser', the chrome URL would be <a class=" external" href="chrome://browser/content/browser.xul" rel="freelink">chrome://browser/content/browser.xul</a>. The final field is the path where the files are located. This can be either a local file path using a file URL or a JAR archive using a jar URL, which will be described in a moment. You can specify multiple packages by including another line in the manifest file.</p>
<p>Firefox的 browser.manifest 长的像这样:</p>
<pre>content branding jar:browser.jar!/content/branding/ xpcnativewrappers=yes
content browser jar:browser.jar!/content/browser/ xpcnativewrappers=yes
overlay chrome://global/content/viewSource.xul chrome://browser/content/viewSourceOverlay.xul
overlay chrome://global/content/viewPartialSource.xul chrome://browser/content/viewSourceOverlay.xul
overlay chrome://browser/content/pageInfo.xul chrome://pippki/content/PageInfoOverlay.xul
</pre>
<p>Two packages are listed here, 'branding' and 'browser'. Three overlays are also specified, which allow content from different packages to combine together. Extensions will make the most use of overlays, since they merge their UI with the browser UI.</p>
<p>The file paths for the branding and browser packages use jar URLs as the content is packaged up into an archive. A JAR archive can be created with a ZIP utility. For a JAR file located in the chrome directory, the syntax is fairly simple:</p>
<p>jar:&lt;filename.jar&gt;!/&lt;path_in_archive&gt;</p>
<p>For the browser package, the archive is browser.jar, located alongside the manifest file in the chrome directory. The path 'content/browser' specifies the path inside the archive where the XUL files are located. You won't need to specify a path if you don't have any directories in the archive. In this case, there is, since the files for the branding package are stored in a different path in the same archive.</p>
<p>For the 'tests' package created above, the files are not packaged into an archive, so a direct file path is used instead. This is good for development since you don't have to package up all the files every time you change them. However, when distributing an application or extension, you will want to package them into an archive to avoid having to install lots of smaller files.</p>
<p>The xpcnativewrappers=yes part at the end of the manifest line is a flag that may optionally be used. In JavaScript, it is possible for a web page to override built-in functions with their own code. If the xpcnativewrappers flag is specified, it indicates that scripts running in a privileged context don't call these overriden versions, but the original built-in versions instead. Otherwise, if an extension attempted to call the modified versions, it would likely not work properly, or worse, create a security hole. This flag was added to prevent this problem and should always be used for newer extensions, but is left out for older extensions that might not be compatible with the change. For more information about this feature, see <a href="../../../../en/XPCNativeWrapper" rel="internal">XPCNativeWrapper</a>.</p>
<h3 class="editable"><span>Themes and Locales</span>
<div class="editIcon"><a href="/../../../../en/XUL_Tutorial/Manifest_Files#" style="visibility: hidden;" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="../../../../skins/common/icons/icon-trans.gif"></span></a></div>
</h3>
<p>The themes and locales, the syntax is similar as for content packages, but you also need to specify the content package you are providing a theme or locale for. For example:</p>
<pre>skin browser classic/1.0 jar:classic.jar!/skin/classic/browser/
locale browser en-US jar:en-US.jar!/locale/browser/
</pre>
<p>For these, the extra field has been added to indicate that the skin and locale applies to the browser. The skin name is 'classic/1.0'. In this case, a version number is being used as part of the theme name, but that is optional if you are making your own theme. Mozilla doesn't handle the version number in a special way; the version number is just part of the theme name. The locale is 'en-US'. The chrome URLs that these would map to would be <a class=" external" href="chrome://browser/skin/browser.css" rel="freelink">chrome://browser/skin/browser.css</a> and <a class=" external" href="chrome://browser/locale/browser.dtd" rel="freelink">chrome://browser/locale/browser.dtd</a>. If you were creating your own theme or locale for the browser, all you need to do is create a manifest file with one of these two lines in it, modified to suit your theme or locale.</p>
<p>For more information about Themes, see <a href="../../../../en/Themes" rel="internal">Themes</a>. For more information about Locales, see <a href="../../../../en/Localization" rel="internal">Localization</a>.</p>
<div class="highlight">
<div id="section_4">
<h3 class="editable"><span>Our example find files dialog</span>
<div class="editIcon"><a href="/../../../../en/XUL_Tutorial/Manifest_Files#" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="../../../../skins/common/icons/icon-trans.gif"></span></a></div>
</h3>
<p>Let's create a manifest file for the find files dialog we'll be creating. You can combine all of the three types into a single file if you wish. This may be done when creating an extension such that all of the parts are in one file. We will do this for the find files dialog. Create a file findfile.manifest in the chrome directory. Add the following to the file:</p>
<pre>content findfile file:///findfile/content/
skin findfile classic/1.0 file:///findfile/skin/
locale findfile en-US file:///findfile/locale/
</pre>
<p>Create the new directories listed above. It doesn't matter where the directories are created, but the file paths in the manifest file should point to the directories. Naturally, you will want to use directory paths suitable for your system. If we were distributing the package, we would want to package them up into a JAR file, and modify the paths. In this case, we are just creating to demonstrate a manifest file and to prepare directories for examples which will see in the later sections.</p>
<p>Note how the second field of the skin and locale lines specifies 'findfile'. This means that the skin and locale modify the findfile package, which was specified on the first line.The three paths above specify subdirectories for each part. You will want to create these subdirectories to keep each part's files separate.</p>
<p> </p>
</div>
</div>
<div id="section_5">
<h3 class="editable"><span>Installing a Package</span>
<div class="editIcon"><a href="/../../../../en/XUL_Tutorial/Manifest_Files#" style="visibility: hidden;" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="../../../../skins/common/icons/icon-trans.gif"></span></a></div>
</h3>
<p>For an application to be installed, you will need to create an installer for it, or include it as part of another application. The method used depends on what kind of application you are creating. For extensions, you will need to create an install file <a href="../../../../en/Install_Manifests" rel="internal">install.rdf</a> which describes what will be installed, the author of the extension and which versions of the browser or other applications it is compatible with. <a href="../../../../en/Bundles" rel="internal">A specific directory structure</a> is needed as well since extensions are limited in where the files may be installed to. An extension is packaged up into an <a href="../../../../en/XPI" rel="internal">XPI</a> file. XPI is short for <a href="../../../../en/XPInstall" rel="internal">XPInstall</a> and is used by Mozilla to install components. Like a JAR file, an XPI file is just a ZIP file with a different extension, so you can create and view XPI files with a ZIP utility.</p>
<p>Firefox's extension manager handles installing extensions packaged into XPI files automatically. It is recommended to upload extensions to the <a class="link-https" href="https://addons.mozilla.org/" rel="external nofollow" target="_blank" title="https://addons.mozilla.org/">Mozilla Add-ons site</a>, where users can locate them for installation. While they may be installed from any site, other sites are not configured to allow installations by default.</p>
<p>It is also possible to use a install script written in JavaScript to install files. This allows you to copy files to any location and perform other file management tasks. However, applications installed with a script will not be listed in the extension manager and there is no automated method to uninstall them. For this reason, the install scripts are not used often.</p>
<p>For standalone applications, they can be packaged up using XULRunner. This allows a separate executable file, and the application may be distributed independently of a browser.</p>
<p>For more information about creating extensions, see <a href="../../../../en/Extensions" rel="internal">Extensions</a>. For more information about XULRunner, see <a href="../../../../en/XULRunner" rel="internal">XULRunner</a>.</p>
</div>
<div id="section_6">
<h3 class="editable"><span>Older Applications</span>
<div class="editIcon"><a href="/../../../../en/XUL_Tutorial/Manifest_Files#" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="../../../../skins/common/icons/icon-trans.gif"></span></a></div>
</h3>
<p>If you are creating applications for older versions of Mozilla software, that is, before Firefox 1.5 or Mozilla 1.8, the process is a bit more involved. The following describes how to set up a package for earlier versions. This section may be skipped if you are writing new extensions or XUL applications.</p>
<div class="note"><strong>Note</strong>: This older process does also apply to the new SeaMonkey 1.0 though. The codebase there has not yet adopted the <em>"Manifest"</em> format.</div>
<ol> <li>Create a directory somewhere on your disk. Many people put this as a subdirectory inside Mozilla's chrome directory, but this isn't necessary. The directory could be anywhere and on any disk. Put your XUL files in this directory.</li> <li>Create a file called contents.rdf and place it in this directory. Copy the text in the box below into the new contents.rdf file. This file is used to identify the application id, its name, author, version and so on.</li> <pre class="eval">&lt;?xml version="1.0"?&gt;

&lt;RDF:RDF xmlns:RDF="<a class=" external" href="http://www.w3.org/1999/02/22-rdf-syntax-ns#" rel="freelink">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a>"
         xmlns:chrome="<a class=" external" href="http://www.mozilla.org/rdf/chrome#" rel="freelink">http://www.mozilla.org/rdf/chrome#</a>"&gt;

  &lt;RDF:Seq about="urn:mozilla:package:root"&gt;
    &lt;RDF:li resource="urn:mozilla:package:<span class="highlightred">myapplication</span>"/&gt;
  &lt;/RDF:Seq&gt;

  &lt;RDF:Description about="urn:mozilla:package:<span class="highlightred">myapplication</span>"
          chrome:displayName="<span class="highlightblue">Application Title</span>"
          chrome:author="<span class="highlightblue">Author Name</span>"
          chrome:name="<span class="highlightred">myapplication</span>"
          chrome:extension="true"/&gt;

&lt;/RDF:RDF&gt;
</pre> <li>Change the highlighted parts of the file above to your own information. The red text 'myapplication' should be the ID of your application. You make this up, but typically, the ID is similar to your application's name. Replace the blue highlighted text above with your application's title and author.</li> <li>If the 'chrome:extension' field is true, the application is a Mozilla Firefox Extension and it will show up in the Extensions window of the browser. If false, it will not appear.</li> <li>Save the contents.rdf and make sure it is in the directory you created in step 1.</li> <li>Open the file &lt;mozilla-directory&gt;/chrome/installed-chrome.txt, where &lt;mozilla-directory&gt; is the directory where Mozilla is installed. Exit Mozilla before you do this.</li> <li>Next, you are going to register the new application with Mozilla so it will know where to find it. Add a line at the end of installed-chrome.txt pointing to the new directory you created in step 1. Change the highlighted text to the file URL below of the directory. Make sure that it URL ends with a slash and that you press enter at the end of the line. If you aren't sure what the URL is, open the directory created in step 1 into a Mozilla browser and copy the URL from the location field. Note that the reference should always be a directory, not a file.</li> <pre class="eval">content,install,url,<span class="highlightred"><a class=" external" href="file:///main/app/" rel="freelink">file:///main/app/</a></span>
</pre> <li>Delete the file &lt;mozilla-directory&gt;/chrome/chrome.rdf.</li> <li>Start Mozilla. You should be able to view any XUL files you put into the directory using a URL of the form: <strong><a class=" external" href="chrome://" rel="freelink">chrome://</a><span class="highlightred">applicationid</span>/content/file.xul</strong> where file.xul is the filename. Your main XUL file should be applicationid.xul which you can load using the shortcut URL <strong><a class=" external" href="chrome://" rel="freelink">chrome://</a><span class="highlightred">applicationid</span>/content/</strong>.</li>
</ol>
<p>If you are creating skin and/or locale portions, repeat the steps above, except that the format of the contents.rdf file is slightly different. Look at the contents.rdf files in other applications for details.</p>
</div>
<h3 class="editable"><span>Troubleshooting</span>
<div class="editIcon"><a href="/../../../../en/XUL_Tutorial/Manifest_Files#" style="visibility: hidden;" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="../../../../skins/common/icons/icon-trans.gif"></span></a></div>
</h3>
<p>Creating a chrome package can often be tricky and it is difficult to diagnose problems. Here are a few tips in case you get stuck.</p>
<ul> <li>Open the file &lt;mozilla-directory&gt;/chrome/chrome.rdf. You should find references to your application ID in there. If not, something is wrong with registration. If it is there, you are probably using the wrong chrome URL when you load the file.</li> <li>Try deleting the &lt;mozilla-directory&gt;/chrome/chrome.rdf file. It will get regenerated. Also delete the entire &lt;mozilla-directory&gt;/chrome/overlayinfo/ directory if you are using overlays.</li> <li>Make sure that the URL in the line you added to installed-chrome.txt ends with a slash and the file itself ends with a blank line.</li> <li>On Windows, file URLs are of the form <a class=" external" href="file:///C" rel="freelink">file:///C</a>|/files/app/, where C is the drive letter.</li> <li>Make sure the contents.rdf file is in the right directory and is well-formed. Open the contents.rdf file in Mozilla to see if it parses as well-formed XML. If not, you will see an error on a yellow background.</li> <li>If you are using a debug build of Mozilla, some info will be printed to the terminal when starting up indicating what chrome applications are being checked. Check if your application is listed.</li> <li>The error message "XML Parsing Error: undefined entity" in your XUL file can be caused by an error in the manifest or in the jar file referenced by the manifest. For example, in &lt;!DOCTYPE window SYSTEM "<a class=" external" href="chrome://fireclipse/locale/fireclipse.dtd" rel="freelink">chrome://fireclipse/locale/fireclipse.dtd</a>"&gt; the dtd file must exist and its directory must be correctly addressed in the "locale" manifest or XML parsing will fail.</li>
</ul>
<p>For more information about manifest files, see <a href="../../../../en/Chrome_Registration" rel="internal">Chrome Registration</a>.</p>
<p>In the next section, we will start looking into the XUL language.</p>
恢复到这个版本