このセクションでは、chrome と XUL ファイルをパッケージする方法と、それらのためにマニフェストファイルを作成する方法について確認します。
パッケージ
パッケージとは、ユーザインタフェースの機能を定義する 一式の XUL ファイルとスクリプトのことです。 パッケージは、Mozilla にインストールされた後、通常は chrome URL によって参照されることになります。 パッケージには、どんな種類のファイルでも含めることができ、多くの場合、パッケージを構成するパートごとに、サブディレクトリに振り分けて置かれます。 パッケージはディレクトリとしても、JAR アーカイブとしても保存することが可能です。
マニフェストファイル
マニフェストファイルは、パッケージについての記述を行い、パッケージのディスク上の位置を chrome URL へマッピングする情報を提供します。 chrome ディレクトリに置かれたマニフェストファイルは、Mozilla アプリケーションが起動するときに、インストールされているパッケージを確認するために調べられていきます。 つまり、新しいパッケージをインストールするために必要なことは、マニフェストファイルを、アプリケーションの chrome ディレクトリかユーザ固有の chrome ディレクトリのどちらかに追加することだけになります。 通常、ユーザ固有の chrome ディレクトリは、パッケージのインストール時、アプリケーションディレクトリに書き込むために十分な権限がない場合に使用されます。
もし Firefox ブラウザで特権が必要な XUL コードをテストしてみたいのであれば、以下の手順で 1 行だけのマニフェストを作成するだけで簡単に行うことが可能です。
- 新しいディレクトリをどこかに作成します。 例として、Windows マシンで、C:\testfiles を使用することにします。
- Firefox がインストールされているディレクトリにある chrome ディレクトリに test.manifest という名前で新しいファイルを ASCII1 形式で作成します (1. BOM 付の UTF-8 形式では動作しません) 。 実際には、
.manifest拡張子になってさえいればよいため、(拡張子を除いた) ファイル名の部分は重要ではありません。 - そのファイルに以下の行を加えます。
content tests file:///C:/testfiles/
加えた行に含まれているファイルパスは、上で作成したディレクトリを指す必要があります。 もし、ディレクトリのファイルパスがわからないのであれば、ブラウザでそのディレクトリを開いて、アドレス欄から URL をコピーしてください。
これだけで完了です! 後は、いくつかの XUL ファイルを、作成したディレクトリに追加することが必要なだけです。 それが済めば、chrome://tests/content/<ファイル名> の形式の chrome URL をタイプすることにより、それらのファイルをロードすることができるはずです。 ただし、変更を有効にするためには、一度ブラウザを再起動する必要はあります。 もし、ファイルがロードされない場合は、ファイルパスが正しいかをもう一度確認してみてください。
コンテントパッケージのためのマニフェストファイルの基本的な文法は以下になります。
'content <packagename> <filepath>'
最初のフィールドに置かれた「content」は、コンテントパッケージであることを示しています。 テーマの場合は「skin」を、ロケール の場合は「locale」を置くことになります。 packagename は、上の例では 「tests」になります。 これは、chrome://tests/content/sample.xul の「tests」のように、chrome URL における最初のフィールドになります。 パッケージ名が「browser」の場合は、chrome URL は chrome://browser/content/ になります。 最後のフィールドはファイルが置かれているパスです。 ここには、ファイル URL によるローカルなファイルパスか、jar URL による JAR アーカイブのどちらかで指定することが可能です。 (jar アーカイブについては、もう少し後で説明します)。 マニフェストァイルに、別の行を加えることで、複数のパッケージを指定することも可能です。
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
ここでは「branding」と「browser」の 2 個のパッケージがリストされています。 また、他のパッケージに含まれているコンテンツに結合させるための 3 つのオーバーレイが指定されています。 このオーバーレイは、拡張機能によって追加される UI (ユーザインタフェース) を、元のブラウザの UI に統合するために、最も多く利用されることになると思います。
branding と browser パッケージのファイルパスは、コンテントがアーカイブにまとめられているため、jar URL を使用しています。 JAR アーカイブは、ZIP ユーティリティで作成することができます。 chrome ディレクトリに置かれた JAR ファイルを指定するための文法は、いたって単純です。
jar:<filename.jar>!/<path_in_archive>
browser パッケージの場合、アーカイブファイルは browser.jar で、(ファイル名だけが記述されているため) chrome ディレクトリに置かれているマニフェストファイルと同じ場所に置かれていることを示しています。 パス「content/browser」は、アーカイブ中で XUL ファイルが置かれている場所を指定しています。 もしアーカイブにディレクトリが含まれない場合は、パスを指定する必要はありません。 今回の場合は、branding パッケージのファイルが同じアーカイブに異なったパスで格納されているため指定する必要があります。
上に作成された 「tests」パッケージでは、ファイルはアーカイブにまとめられていないので、ファイルへの直接パスが代わりに使用されています。 開発中であれば、ファイルを変更したときに毎回すべてのファイルをアーカイブし直す必要がないため、この方法が良いと思います。 しかし、完成したアプリケーションや拡張機能を配布するときは、小さなファイルがたくさんインストールされるのを避けるためにアーカイブにまとめたくなると思います。
マニフェスト行の終わりにある xpcnativewrappers=yes の部分は、付加的に使用されるフラグです。 JavaScript では、Web ページが自前のコードで組込み関数をオーバライドすることが可能です。 xpcnativewrappers フラグが指定されている場合、それらのスクリプトが、特権を持ったコンテキストで実行されるとき、オーバライドされた方の関数ではなく、オリジナルの組み込み関数を呼ぶことを指定します。 そうしないと、もし拡張機能が変更された方の関数を呼ぶことを試みた場合、おそらく適切に動作しないと思われますし、さらに悪いケースではセキュリティ ホールになる可能性もあります。 このフラグは、こういった問題を防ぐために加えられたため、新しい拡張機能では、常に使用されるべきですが、この変更に対して互換性がないかもしれない古い拡張機能のために、使用しない指定も残されています。 この機能についての詳細は XPCNativeWrapper を参照してください。
テーマとロケール
テーマと ロケールパッケージの文法は コンテントパッケージと類似していますが、コンテントパッケージで指定したのと同じフィールドに加えて、何のテーマまたはロケールを提供するのかを指定する必要があります。 以下に例を示します。
skin browser classic/1.0 jar:classic.jar!/skin/classic/browser/ locale browser en-US jar:en-US.jar!/locale/browser/
これらには、browser に適用されるスキンとロケールについて示すために、専用のフィールドが加えられています。 このスキンの名前は 「classic/1.0」になります。 バージョン番号がテーマ名の一部として使用されていますが、独自にテーマを作成する場合、バージョン番号の使用は任意でかまいません。 Mozilla ではバージョン番号を扱うための特別な方法はなく、バージョン番号は単にテーマ名の一部です。 ロケールの方は「en-US」であることを示しています。 これらの chrome URL は、chrome://browser/skin と、chrome://browser/locale にマッピングされます。 もし、ブラウザのために、独自のテーマかロケールを作成しているのであれば、必要な作業は、上記の 2 行のうちの必要な方を書いたマニフェストファイルを作成して、作成するテーマかロケールに合うように変更することだけです。
テーマに関する詳しい情報に関しては、Themes を参照してください。 ロケールに関する詳しい情報に関しては、Localization を参照してください。
ファイル検索ダイアログの例
それでは、これから作成していくファイル検索ダイアログのために、マニフェストファイルを作成してみましょう。 必要なら、上記の 3 つのタイプのすべてを 1つのファイルに結合することも可能です。 これは 1 個のファイルの中に全てのパートがあるような拡張を作成するような場合などに利用されます。 ファイル検索ダイアログでは、これを利用してみることにします。 chrome ディレクトリに findfile.manifest という名前でファイルを作成し、以下をファイルに追加してください。
content findfile file:///findfile/content/
skin findfile classic/1.0 file:///findfile/skin/
locale findfile en-US file:///findfile/locale/
上でリストされたように新規のディレクトリを作成してください。 実のところ、ディレクトリは、どこに作成してもかまいませんが、マニフェストファイルのファイルパスが、そのディレクトリを示している必要があります。 当然のことですが、実際には自分のシステムに応じたディレクトリパスを使用したいはずです。 もし、このパッケージを配布するのであれば、JAR ファイルにパッケージして、パスを変更したいと思うでしょう。 今回は、マニフェストファイルの実例を示すことと、今後のセクションで作成していく例のためにディレクトリを準備することが目的のため、このように作成しておきます。
また、skin と locale の行の 2番目のフィールドが「findfile」を指定していることにも注意してください。 これは、skin と locale が、最初の行で指定された「findfile」パッケージを変更するものであることを示しています。
上の 3 つのパスは、各パートのためのサブディレクトリを指定しています。 各パートのファイルを分けたままにしたい場合は、このようにサブディレクトリを作成しておきます。
パッケージのインストール
どのようなアプリケーションを作成しているかによって方法は変わると思いますが、一般的にアプリケーションをインストールするためには、そのためにインストーラを作成するか、または別のアプリケーションの一部として含めておく必要があると思います。
拡張機能の場合、「何がインストールされるか」、「その拡張機能の作者」、「ブラウザまたは他のアプリケーションのどのバージョンに適合するか」を記述するために、インストールファイルとして install.rdf を作成する必要があります。 拡張機能は、ファイルインストール先に制限があるため、それにあわせた専用のディレクトリ構造も必要です。 拡張機能は XPI ファイルの中にパッケージされます。 XPI は、XPInstall の短縮であり、Mozilla によってコンポーネントをインストールするのに使用されます。 JAR ファイルのように、XPI ファイルは単に拡張子が異なるだけの ZIP ファイルであるため、ZIP ユーティリティによって XPI ファイルを作成したり、見たりすることが可能です。
Firefox の拡張機能マネージャは、XPI ファイルの中にパッケージされた拡張機能を自動的に扱いインストールします。 作成した拡張機能を Mozilla Add-onsサイトにアップロードするのはお勧めです。 そうしておけば、利用者がインストールしたいとき、簡単に配布元を見つけることができるようになります。 拡張機能は、どんなサイトからでもインストールすることは可能ですが、Firefox は、それ以外のサイトでは、デフォルトでインストールを許容するように構成されていません。
ファイルをインストールするために JavaScript に書かれたインストールスクリプトを使用することも可能です。 この方法では、どんな位置にもファイルをコピーすることが可能で、他のファイル管理タスクの実行することも出来ます。 しかしながら、スクリプトでインストールされたアプリケーションは、拡張機能マネージャによってリストされず、それらをアンインストールするための自動化された方法もありません。 この理由のために、インストールスクリプトは頻繁に使用されることはありません。
スタンドアローンなアプリケーションは、XULRunner を使用してパッケージすることが可能です。 これによって、実行可能ファイルを分離して、アプリケーションをブラウザによらずに配布することができるようになります。
拡張機能を作成することに関する詳しい情報に関しては、Extensions を参照してください。 XULRunner に関する詳しい情報に関しては、XULRunner を参照してください。
古いアプリケーション
もし、Mozilla ソフトウェアの旧式のバージョンのアプリケーションを作成する場合、すなわち、Firefox 1.5 か Mozilla1.8 のより前の版のためには、プロセスはもう少し込み入っています。 以下は、以前のバージョンのためのパッケージをセットアップする方法を説明します。 もし、新しい拡張か XUL アプリケーションを書いているのであれば、このセクションはスキップしてもかまいません。
<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="https://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:chrome="https://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>
content,install,url,file:///main/app/
- ディレクトリをディスクの上のどこかに作成してください。 多くの人は、サブディレクトリとして Mozilla の chrome ディレクトリに作成しますが、必須ではありません。ディレクトリは、どこでも、どんなディスクの上に置いてもかまいません。その作成したディレクトリに XUL ファイルを入れてください。
- contents.rdf と呼ばれるファイルを作成し、同じディレクトリに置いてください。以下の囲いのテキストを、新しい contents.rdf ファイルにコピーしてください。 このファイルは、アプリケーションID、名前、作者、バージョンなどを特定するのに使用されます。
- ファイルで上で強調された部分をあなた自身の情報に変更してください。 赤いテキスト「myapplication」はあなたの作成するアプリケーションの ID である必要があります。この内容を設定するとき、多くの場合、ID はあなたのアプリケーションの名前と類似したものします。 上で青く強調されたテキストはあなたのアプリケーションのタイトルと作者に置き換えてください。
- もし、「chrome:extension」フィールドが true ならば、アプリケーションは Mozilla Firefox の拡張機能であることを示します。このため、ブラウザの 拡張のウィンドウに表示されるはずです。false の場合は、表示されません。
- contents.rdf を保存して、それがあなたがステップ 1 で作成したディレクトリに置かれていることを確認して下さい。
- ファイル <mozilla-directory>/chrome/installed-chrome.txt を開いてください。<mozilla-directory> は Mozilla がインストールされているディレクトリです。開く前に Mozilla を終了させて下さい。
- 次に、Mozilla に新しいアプリケーションを登録することによって、Mozilla がどこから新しいアプリケーションを見つけるかを理解します。まず、あなたが ステップ 1 で作成した新しいディレクトリを示すための行を、installed-chrome.txt の最後に加えてください。以下の強調されたテキストで示されるファイル URL のディレクトリ部分を変更して下さい。URL が確実に スラッシュで終わっていることと、行の最後で改行が押されたことを確認して下さい。URL が何であるかを確認出来ないのであれば、ステップ 1 で作成したディレクトリを Mozilla ブラウザに開いてください。そして、ロケーションフィールドから URL をコピーしてください。この参照がファイルでなく、常にディレクトリであるべきであることに注意してください。
- ファイル <mozilla-directory>/chrome/chrome.rdf を削除してください。
- Mozilla を起動します。
chrome://applicationid/content/file.xul(file.xulはファイル名) の形式でディレクトリに置かれた任意の XUL ファイルを参照することが可能なはずです。メインの XUL ファイルの名前はchrome://applicationid/content/のショートカット URL を使用してロード可能な applicationid.xul にするべきです。
スキン、そして/または、ロケールの部分を作成しているのであれば、contents.rdf ファイルの形式がわずかに異なっているのを除き、上のステップを繰り返してください。詳細は他のアプリケーションにおける contents.rdf ファイルを見てください。
トラブルシューティング
クロムパッケージを作成するとき、しばしばトリッキーなことがあり、それが問題の原因を判断するのを難しくしています。ここに、あなたが立ち往生したときのためにいくつかの Tipsを書いておきます。【訳注: この部分の記述は、「古いアプリケーション」のためのものがほとんどのようです】
- ファイル <mozilla-directory>/chrome/chrome.rdf を開きます。そこで、あなたのアプリケーションIDのへの参照が見つけられるはずです。見つからないなら、登録に何か問題があります。見つかった場合は、ファイルをロードするときに、間違った chrome URL を使用しているのかもしれません。
- <mozilla-directory>/chrome/chrome.rdf ファイルを削除してみます。 削除しても作り直されるはずです。 また、あなたがオーバレイを使用しているなら、(<mozilla-directory>)/chrome/overlayinfo/ ディレクトリ全体を削除してみます。
- あなたが installed-chrome.txt に加えた行の URL がスラッシュで終わっていることと、そのファイルが空白行で終わっているのを確認します。
- Windows では、ファイルURLの形式は
file:///C|/files/app/、C はドライブ名になります。(C:でもかまいません) - contents.rdf ファイルが正しいディレクトリにあって、形式に誤りがないことを確認します。正しい形式の XML として解釈されているかどうかを確認するためには、Mozilla で contents.rdf ファイルを開きます。形式に誤りがある場合、黄色い背景色によりエラー箇所を見つけることが出来ます。
- デバッグ用にビルドされた Mozilla を使用すれば、起動時にチェックされた chrome アプリケーションについていくつかの情報が端末に表示されるはずです。あなたのアプリケーションがリストされているかどうかを確認します。
- 「XML Parsing Error: undefined entity」というエラーメッセージが XUL ファイルで出力された場合は、マニフェストファイルか、そのマニフェストが参照している jar ファイルに誤りがあります。例えば、XUL ファイルに「
<!DOCTYPE window SYSTEM "chrome://fireclipse/locale/fireclipse.dtd">という記述がある場合は、その DTD が存在して、かつマニフェストのlocaleで、正しく指定されていないと、「XML の解析 (parsing)」に失敗することになます。
マニフェストファイルについての詳細な情報が必要な場合は、Chrome Registration を参照してください。
次のセクションでは、 XUL 言語についての説明を始めます。