Chrome Registration

Chrome (クロム) とは?

Chrome とは、アプリケーションウィンドウで、そのウィンドウのコンテンツ領域の外側にあるユーザーインターフェイス要素のセットのことです。 ツールバーやメニューバー、プログレスバー、およびウィンドウタイトルバーといった要素は、全て chrome の部分の典型的な例になります。

Mozilla は拡張機能とテーマについて、ルートディレクトリに置かれた chrome.manifest を認識します。

Chrome プロバイダ

ある種類のウィンドウ (例: ブラウザ用ウィンドウ) のための chrome の供給元を、chrome プロバイダと呼びます。 特定のウィンドウに対して、ツールバー上に表示する画像から利用するテキストを記述したファイルまで、 コンテンツとウィンドウ自身の外観のための完全な chrome のセットを供給するために、 複数のプロバイダが一緒に動作することになります。

chrome プロバイダの 3 つの基本型を以下に示します。

コンテント

ウィンドウを記述するための主要なソースファイルは、コンテントプロバイダから供給されます。 これらは Mozilla の中から参照可能な任意の種類のファイルであることが可能ですが、 典型的には、ウィンドウやダイアログを記述するために設計されている XUL ファイルになります。 また、ユーザーインターフェイスを定義する JavaScript ファイルもコンテントパッケージに含まれ、 ほとんどの XBL バインディングファイルも同様です。

ロケール

ローカライズ可能なアプリケーションは、全てのローカライズのための情報をロケールプロバイダに保持します。 これにより、翻訳者は別の chrome パッケージを差し込むだけで、ソースコードのそれ以外の部分を変更することなく、アプリケーションの翻訳を行うことが可能になります。 ローカライズ可能な主なファイルは、DTD ファイルと Java スタイルのプロパティファイルの 2 つになります。

スキン

スキンプロバイダは、chrome の視覚的な外観を記述するための、完全なファイルのセットを提供する役割を持っています。 典型的なスキンプロバイダは、CSS ファイルと画像を提供することになります。

Chrome レジストリ

Gecko の実行環境は、chrome レジストリとして知られる、chrome パッケージ名から chrome パッケージのディスク上の物理的な位置へのマッピングを提供するサービスを保守しています。

この chrome レジストリが、コンフィグ可能で永続的であるため、 利用者は異なった chrome プロバイダをインストールして、好みのスキンやロケールを選択することが可能になります。 これは、xpinstall と、拡張マネージャによって実現されます。

利用可能な chrome の chrome レジストリの情報のために、テキストのマニフェストが使用されます。 このマニフェストは、拡張機能やテーマのルートに置かれた「chrome.manifest」であり、XULRunner アプリケーションの chrome/*.manifest に該当します。

このプレインテキストの chrome マニフェストは、以下のような単純な行ベースのフォーマットになっています。 各行は個々に解釈されます。 つまり、その行が chrome レジストリにとって解釈可能な場合は、その行で指定される動作を行い、 不可能な場合 chrome レジストリはその行を無視します。 (警告メッセージが実行時エラーのコンソールに出力されます)

locale パッケージ名 ロケール名 path/to/files
skin パッケージ名 テーマ名 path/to/files

マニフェスト命令 (Instruction)

コメント

文字 '#' で始まる行はコメントです。 その行のそれ以降の文字は全て無視されます。

# この行はコメントです。ここには何でも書けます。

manifest

manifest サブディレクトリ /foo.manifest [フラグ]

この指定は追加のマニフェストファイルを読み込みます。これはコンポーネントや chrome の登録、プラットフォーム依存の登録用の指定を別ファイルに分割する場合に便利かもしれません。

binary-component

binary-component components/mycomponent.dll [フラグ]

Mozilla に対して、バイナリ形式のコンポーネントを登録し利用するよう指示します。コンポーネントが ABI に依存する物である場合には、これは abi フラグと同時に使用されるべきです。Firefox 4 よりも前のバージョンでは、components ディレクトリにあるファイルは自動的に登録されていました。

interfaces

interfaces components/mycomponent.xpt [フラグ]

Mozilla に対して、XPIDL によって生成された typelib ファイルからインターフェースの情報を読み込むよう指示します。Firefox 4 よりも前のバージョンでは、components ディレクトリにあるファイルは自動的に登録されていました。

component

component {00000000-0000-0000-0000-000000000000} components/mycomponent.js [フラグ]

Mozilla に対して、JavaScript（あるいはその他の利用可能なスクリプト言語）で記述された XPCOM コンポーネントの実装についてコンポーネントの CID の情報を与えます。クラスID {0000...} はそのコンポーネントによって実装されているクラスIDと一致しなくてはなりません。

contract

contract @foobar/mycontract; {00000000-0000-0000-0000-000000000000} [フラグ]

コントラクト ID（ヒューマンリーダブルな文字列）を特定の実装のクラス ID にマッピングします。一般的には、1つのコントラクト ID はその直前に書かれた component エントリと対にして記述されるでしょう。

category

category カテゴリ名 エントリ名 値 [フラグ]

エントリをカテゴリーマネージャに登録します。カテゴリによって、記述する内容の形式や意味は変わります。

content

この行により、コンテントパッケージが登録されます。

content パッケージ名 uri/to/files/ [フラグ]

これによって、URI chrome://パッケージ名/content/... によって参照された場合に実際のファイルシステム上の場所を解決するための情報が登録されます。 URI は、絶対指定か、このマニフェストファイルからの相対パスを指定します。 この URI 指定は、'/' で終了している必要があることに注意してください。

locale

この行により、ロケールパッケージが登録されます。

locale パッケージ名 ロケール名 uri/to/files/ [flags]

これによって、URI chrome://packagename/locale/... によって参照されるロケールパッケージを登録します。 ロケール名 は、「en」のように言語だけの識別子か、「en-US」のような「言語-国」の識別子になります。 もし、そのパッケージに複数のロケールが登録されている場合、 chrome レジストリは、利用者の設定に最もふさわしいロケールを選択して利用することになります。

skin

この行により、スキンパッケージが登録されます。

skin パッケージ名 スキン名 uri/to/files/ [フラグ]

これによって、URI chrome://packagename/skin/... によって参照されるスキンパッケージを登録します。 スキン名 にはインストールされるスキンを識別する適当な文字列を指定します。 もし、そのパッケージに複数のスキンが登録されている場合、 chrome レジストリは、利用者の設定に最もふさわしいスキンを選択して利用することになります。

overlay

XUL オーバーレイは、以下の構文で登録されます。

overlay chrome://オーバーレイが適用されるURI chrome://適用するオーバーレイのURI [フラグ]

style

スタイルオーバーレイ (chrome ページに適用するためのカスタム CSS) は、以下の構文で登録されます。

style chrome://スタイルが適用されるURI chrome://スタイルシートのURI [フラグ]

override

拡張機能や embedder で、アプリケーションや XULRunner が提供しているファイルをオーバーライドしたくなるケースがあります。 これは、chrome 登録マニフェストの 「override」命令で可能になります。

override chrome://package/type/オーバーライドされる元のURI オーバーライドするURI [フラグ]

注: override 指定は再帰的には適用されません。（ですので、chrome://foo/content/bar/ を file:///home/john/blah/ でオーバーライドしても、大抵の場合は意図した通りには動作しないでしょう。

resource

JavaScript コードモジュール を利用する場合、拡張機能やアプリケーションがComponents.utils.import を使用してモジュールを読み込めるようにするために、resource プロトコルのエイリアスを作成する必要があるでしょう。エイリアスは resource 行を使うことによって作られます:

resource エイリアス名 uri/to/files/ [flags]

これは resource://<エイリアス名>/ という URI に対して、与えられたパスへのマッピングを行います。

マニフェストフラグ

マニフェストの行は、空白区切りにより複数のフラグを持つことができ、 それらは登録行の最後に追加します。 これらのフラグは、そのパッケージの chrome に特殊な属性をマークしたり、 その行が使用される条件を制限するために使用されます。

application

拡張機能は、複数のアプリケーションに対してインストールされる可能性があります。 特定のアプリケーションだけに適用する chrome 登録行を置きたい場合には、

application=app-ID

のフラグによって、拡張機能が app-ID で識別されるアプリケーションに対してインストールされる場合にのみ、この命令を適用することを示します。 複数の application フラグを単一の行に含めても構いません。 その場合は、その中のいずれかが一致した場合に適用されることになります。

これは、異なるアプリケーションに対してどのように異なるオーバーレイを適用するかを示す例です。

overlay chrome://browser/content/browser.xul chrome://myaddon/content/ffOverlay.xul application={ec8030f7-c20a-464f-9b0e-13a3a9e97384}
overlay chrome://messenger/content/mailWindowOverlay.xul chrome://myaddon/content/tbOverlay.xul application={3550f703-e582-4d05-9a08-453d09bdfdc6}
overlay chrome://songbird/content/xul/layoutBaseOverlay.xul chrome://myaddon/content/sbOverlay.xul [email protected]

appversion

拡張機能は、アプリケーションの複数のバージョンに対してインストールされる可能性があります。 特定のバージョンだけに適用する chrome 登録行を置きたい場合には、

appversion=version
appversion<version
appversion<=version
appversion>version
appversion>=version

のフラグによって、拡張機能が識別されたバージョンのアプリケーションにインストールされる場合にのみ、この命令を適用することを示します。 複数の appversion フラグを単一の行に含めても構いません。 その場合は、その中のいずれかが一致した場合に適用されることになります。 なお、バージョン文字列は、Toolkit version format に従っている必要があります。

contentaccessible

chrome のリソースは、信頼されていないソースから読み込まれたページに含まれる、またはそのようなページに挿入された  <img>, <script> またはその他の要素から参照できなくなりました。この制限は、信頼できないソースの中で定義された要素と、信頼された拡張機能によって追加された要素のいずれに対しても適用されます。もしそのような参照を明示的に許可する必要がある場合には、古いバージョンのFirefox と同じ結果を得るために、contentaccessible フラグを yes と指定してください。詳細は バグ 436989 を参照してください。

contentaccessible フラグはコンテントパッケージに対してのみ適用でき、ロケールまたはスキンの登録に対しては無視されます。しかしながら、マッチしたロケールおよびスキンのパッケージは、コンテントパッケージにも露出するでしょう。

注: 古いバージョンの Firefox は contentaccessible フラグを解釈しないため、 Firefox 3 とそれ以前のバージョンの Firefox の両方に対応するよう設計された拡張機能は、フォールバックのための指定を必要とするでしょう。例：

content packagename chrome/path/
content packagename chrome/path/ contentaccessible=yes

これは バグ 292789 のため、Firefox 3 RC 1 において変更されました。

os

拡張機能（およびテーマ）は、Firefoxが動作しているオペレーティングシステムに依存した異なる機能を提供することができます。値はそのプラットフォームの OS_TARGET の値と比較されます。

os=WINNT
os=Darwin

OSの名前のより詳しいリストはOS_TARGETを参照してください。OSの名前は大文字小文字は区別されません。

osversion

拡張機能あるいはテーマは動作しているオペレーティングシステムのバージョンによって異なる挙動を示す必要に迫られることがあります。例えば、あるテーマでMac OS X 10.5（以降）用に、10.4（以前）とは異なる外観を適用したい場合はこのようになります:

osversion>=10.5

abi

コンポーネントが特定の API に対してのみ互換性がある場合、この指定で ABI を記述する事ができます。例：

binary-component abi=WINNT_x86-MSVC 

より詳しい情報は XPCOM ABI を参照してください。

platform (プラットフォーム固有パッケージ)

パッケージの中には、プラットフォーム固有を示すために専用のフラグでマークされているものがあります。 このようなパッケージでは、コンテント、スキン、ロケールのうちのいくつかのパートが、実行されているプラットフォームによって異なっているために、 「Windows と OS/2」、「Macintosh」、「Unix 系」のプラットフォームのために、3 セットの異なるファイルが含まれることになります。 例えば、ダイアログの「OK」と「キャンセル」ボタンの並び順は、プラットフォームによって異なります。 また同様にいくつかの項目の名前も異なっています。

「platform」修飾子は、コンテントの登録の場合のみ解釈され、ロケールとスキンの登録では行われません。 しかしながら、このフラグはパッケージの content、locale、skin のどのパートに対しても、指定されれば適用されます。

そのパッケージがプラットフォーム固有であることを示すためには、 以下の例のように「platform」修飾子を「content」行のパス指定の後に置きます。

content global-platform jar:toolkit.jar!/toolkit/content/global-platform/ platform

これを作成するマニフェストで指定すると、global-platform ディレクトリ以下には、 win (Windows/OS2)、 mac (OS9/OSX)、 unix (それ以外の全て) のサブディレクトリを置く必要があります。 これらのサブディレクトリ以外に置かれた任意のファイルは、全て無視されます。

xpcnativewrappers

Chrome パッケージでは、悪意のあるコンテンツにアクセスした場合に、それらからパッケージのコードを自動的に保護するために、 セキュリティのメカニズムである XPCNativeWrapper を使用するかどうかを決めることができます。 詳細については、chrome から コンテントの DOM に安全にアクセスする方法を参照してください。

このフラグは Firefox 1.5 以前では初期状態で有効となっており、Firefox 4 までの間は、 xpcnativewrappers=no と指定することによって手動で無効化することができました。

xpcnativewrappers フラグは、コンテントパッケージのみに適用され、 ロケールとスキンの登録では識別されません。

Chrome マニフェストの例

content       necko                   jar:comm.jar!/content/necko/
locale        necko       en-US       jar:en-US.jar!/locale/en-US/necko/
content       xbl-marquee             jar:comm.jar!/content/xbl-marquee/
content       pipnss                  jar:pipnss.jar!/content/pipnss/
locale        pipnss      en-US       jar:en-US.jar!/locale/en-US/pipnss/
# Firefox-only
overlay chrome://browser/content/pageInfo.xul           chrome://pippki/content/PageInfoOverlay.xul application={ec8030f7-c20a-464f-9b0e-13a3a9e97384}
# SeaMonkey-only
overlay chrome://navigator/content/pageInfo.xul         chrome://pippki/content/PageInfoOverlay.xul application={92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}
overlay chrome://communicator/content/pref/preftree.xul chrome://pippki/content/PrefOverlay.xul
content       pippki                  jar:pippki.jar!/content/pippki/
locale        pippki      en-US       jar:en-US.jar!/locale/en-US/pippki/
content       global-platform         jar:toolkit.jar!/content/global-platform/ platform
skin          global      classic/1.0 jar:classic.jar!/skin/classic/global/
override chrome://global/content/netError.xhtml jar:embedder.jar!/global/content/netError.xhtml
content       inspector               jar:inspector.jar!/content/inspector/

古い contents.rdf 形式のマニフェスト

プレインテキスト形式のマニフェストの導入 (Firefox 1.5 と Toolkit 1.8 で実施) より前には、"contents.rdf" という名称の RDF によるマニフェストが chrome の登録のために使用されていました。 この形式は非推奨です。 しかしながら、バージョン2より前の SeaMonkey は、プレインテキスト形式のマニフェストをまだサポートしていないため、 Firefox 1.0 に対する後方互換性の維持や、Mozilla スイート への対応が必要な拡張機能では、contents.rdf マニフェストが必要になります。

Toolkit API 公式リファレンス

Official References. Do not add to this list without contacting Benjamin Smedberg. Note that this page is included from the pages listed below. So: Don't Add Breadcrumbs!

• Structure of an Installable Bundle: describes the common structure of installable bundles, including extensions, themes, and XULRunner applications
• Extension Packaging: specific information about how to package extensions
• Theme Packaging: specific information about how to package themes
• Multiple-item Extension Packaging: specific information about multiple-item extension XPIs
• XUL Application Packaging: specific information about how to package XULRunner applications
• Chrome Registration