--- title: Chrome Registration slug: Mozilla/Chrome_Registration tags: - Toolkit API translation_of: Mozilla/Chrome_Registration ---
Chrome とは、アプリケーションウィンドウで、そのウィンドウのコンテンツ領域の外側にあるユーザーインターフェイス要素のセットのことです。 ツールバーやメニューバー、プログレスバー、およびウィンドウタイトルバーといった要素は、全て chrome の部分の典型的な例になります。
Mozilla は拡張機能とテーマについて、ルートディレクトリに置かれた chrome.manifest
を認識します。
{{ gecko_callout_heading("2.0") }}
Gecko 1.9.2 およびそれ以前では、Mozilla はアプリケーションのルートから見て chrome/*.manifest
の位置にあるマニフェストファイルも読み込みます。Gecko 2.0 {{ geckoRelease("2.0") }} 以降では、ルートに置かれた chrome.manifest
だけがマニフェストファイルとして利用されますが、manifest
コマンドを使う事で、任意のファイルを追加のマニフェストファイルとして読み込ませる事ができます。
{{ 英語版章題("Chrome_Providers") }}
ある種類のウィンドウ (例: ブラウザ用ウィンドウ) のための chrome の{{ 訳語("供給元", "supplier") }}を、chrome プロバイダと呼びます。 特定のウィンドウに対して、ツールバー上に表示する画像から利用するテキストを記述したファイルまで、 コンテンツとウィンドウ自身の外観のための完全な chrome のセットを供給するために、 複数のプロバイダが一緒に動作することになります。
chrome プロバイダの 3 つの基本型を以下に示します。
{{ 英語版章題("Content") }}
ウィンドウを記述するための主要なソースファイルは、コンテントプロバイダから供給されます。 これらは Mozilla の中から参照可能な任意の種類のファイルであることが可能ですが、 典型的には、ウィンドウやダイアログを記述するために設計されている XUL ファイルになります。 また、ユーザーインターフェイスを定義する JavaScript ファイルもコンテントパッケージに含まれ、 ほとんどの XBL バインディングファイルも同様です。
{{ 英語版章題("Locale") }}
ローカライズ可能なアプリケーションは、全てのローカライズのための情報をロケールプロバイダに保持します。 これにより、翻訳者は別の chrome パッケージを差し込むだけで、ソースコードのそれ以外の部分を変更することなく、アプリケーションの翻訳を行うことが可能になります。 ローカライズ可能な主なファイルは、DTD ファイルと Java スタイルのプロパティファイルの 2 つになります。
{{ 英語版章題("Skin") }}
スキンプロバイダは、chrome の視覚的な外観を記述するための、完全なファイルのセットを提供する役割を持っています。 典型的なスキンプロバイダは、CSS ファイルと画像を提供することになります。
{{ 英語版章題("The Chrome Registry") }}
Gecko の実行環境は、chrome レジストリとして知られる、chrome パッケージ名から chrome パッケージのディスク上の物理的な位置へのマッピングを提供するサービスを保守しています。
この chrome レジストリが、コンフィグ可能で{{ 訳語("永続的", "persistent") }}であるため、 利用者は異なった chrome プロバイダをインストールして、好みのスキンやロケールを選択することが可能になります。 これは、xpinstall と、拡張マネージャによって実現されます。
利用可能な chrome の chrome レジストリの情報のために、テキストのマニフェストが使用されます。 このマニフェストは、拡張機能やテーマのルートに置かれた「chrome.manifest」であり、XULRunner アプリケーションの chrome/*.manifest に該当します。
このプレインテキストの chrome マニフェストは、以下のような単純な行ベースのフォーマットになっています。 各行は個々に{{ 訳語("解釈", "parse") }}されます。 つまり、その行が chrome レジストリにとって解釈可能な場合は、その行で指定される動作を行い、 不可能な場合 chrome レジストリはその行を無視します。 (警告メッセージが実行時エラーのコンソールに出力されます)
locale パッケージ名 ロケール名 path/to/files skin パッケージ名 テーマ名 path/to/files
{{ 英語版章題("Manifest Instructions") }}
文字 '#' で始まる行はコメントです。 その行のそれ以降の文字は全て無視されます。
# この行はコメントです。ここには何でも書けます。
{{ gecko_minversion_inline("2.0b4") }}
manifest サブディレクトリ /foo.manifest [フラグ]
この指定は追加のマニフェストファイルを読み込みます。これはコンポーネントや chrome の登録、プラットフォーム依存の登録用の指定を別ファイルに分割する場合に便利かもしれません。
{{ gecko_minversion_inline("2.0b2") }}
binary-component components/mycomponent.dll [フラグ]
Mozilla に対して、バイナリ形式のコンポーネントを登録し利用するよう指示します。コンポーネントが ABI に依存する物である場合には、これは abi フラグと同時に使用されるべきです。Firefox 4 よりも前のバージョンでは、components ディレクトリにあるファイルは自動的に登録されていました。
{{ gecko_minversion_inline("2.0b2") }}
interfaces components/mycomponent.xpt [フラグ]
Mozilla に対して、XPIDL によって生成された typelib ファイルからインターフェースの情報を読み込むよう指示します。Firefox 4 よりも前のバージョンでは、components ディレクトリにあるファイルは自動的に登録されていました。
{{ gecko_minversion_inline("2.0b2") }}
component {00000000-0000-0000-0000-000000000000} components/mycomponent.js [フラグ]
Mozilla に対して、JavaScript(あるいはその他の利用可能なスクリプト言語)で記述された XPCOM コンポーネントの実装についてコンポーネントの CID の情報を与えます。クラスID {0000...} はそのコンポーネントによって実装されているクラスIDと一致しなくてはなりません。
{{ gecko_minversion_inline("2.0b2") }}
contract @foobar/mycontract; {00000000-0000-0000-0000-000000000000} [フラグ]
コントラクト ID(ヒューマンリーダブルな文字列)を特定の実装のクラス ID にマッピングします。一般的には、1つのコントラクト ID はその直前に書かれた component エントリと対にして記述されるでしょう。
{{ gecko_minversion_inline("2.0b2") }}
category カテゴリ名 エントリ名 値 [フラグ]
エントリをカテゴリーマネージャに登録します。カテゴリによって、記述する内容の形式や意味は変わります。
この行により、コンテントパッケージが登録されます。
content パッケージ名 uri/to/files/ [フラグ]
これによって、URI chrome://パッケージ名/content/...
によって参照された場合に実際のファイルシステム上の場所を解決するための情報が登録されます。 URI は、絶対指定か、このマニフェストファイルからの相対パスを指定します。 この URI 指定は、'/' で終了している必要があることに注意してください。
この行により、ロケールパッケージが登録されます。
locale パッケージ名 ロケール名 uri/to/files/ [flags]
これによって、URI chrome://packagename/locale/...
によって参照されるロケールパッケージを登録します。 ロケール名 は、「en」のように言語だけの識別子か、「en-US」のような「言語-国」の識別子になります。 もし、そのパッケージに複数のロケールが登録されている場合、 chrome レジストリは、利用者の{{ 訳語("設定", "preference") }}に最もふさわしいロケールを選択して利用することになります。
{{ 訳注("日本語の場合のロケール名について") }}
Firefox 1.5 以上は上位互換性を持っており、ja であろうが ja-JP であろうが問題なく動作します。 但し、*.manifest は ja/ja-JP-mac 世代の製品でしか使いませんから、contents.rdf でどうするかにかかわらず、ja を使用することを推奨します。
Firefox/Thunderbird 1.5 以降での locale の選択は
という規則になっているので、拡張機能側では ja でも ja-JP でも好きな方を指定して動作上問題ありません。 Firefox/Thunderbird 1.5 以降しかサポートしないのに ja-JP を指定するというのはナンセンスですので推奨しませんが、Firefox/Thunderbird 1.0.x や Seamonkey 1.0.x などもサポートするのであれば ja でも ja-JP でも構いません。
※ Mozilla L10N フォーラムの記事 から引用
この行により、スキンパッケージが登録されます。
skin パッケージ名 スキン名 uri/to/files/ [フラグ]
これによって、URI chrome://packagename/skin/...
によって参照されるスキンパッケージを登録します。 スキン名 にはインストールされるスキンを識別する{{ 訳語("適当な", "opaque") }}文字列を指定します。 もし、そのパッケージに複数のスキンが登録されている場合、 chrome レジストリは、利用者の{{ 訳語("設定", "preference") }}に最もふさわしいスキンを選択して利用することになります。
XUL オーバーレイは、以下の構文で登録されます。
overlay chrome://オーバーレイが適用されるURI chrome://適用するオーバーレイのURI [フラグ]
スタイルオーバーレイ (chrome ページに適用するためのカスタム CSS) は、以下の構文で登録されます。
style chrome://スタイルが適用されるURI chrome://スタイルシートのURI [フラグ]
この機能はChrome URIのスタイルシートについてだけ利用できることに注意してください。
{{ 訳語("拡張機能", "extension") }}や embedder で、アプリケーションや XULRunner が提供しているファイルをオーバーライドしたくなるケースがあります。 これは、chrome 登録マニフェストの 「override」命令で可能になります。
override chrome://package/type/オーバーライドされる元のURI オーバーライドするURI [フラグ]
注: override 指定は再帰的には適用されません。(ですので、chrome://foo/content/bar/ を file:///home/john/blah/ でオーバーライドしても、大抵の場合は意図した通りには動作しないでしょう。
Gecko 1.8.1.5(Firefox 2.0.0.5)およびそれ以前のバージョンにはバグがあり、オーバーライドするURI の部分に相対パスを指定できませんでした。そのため、必ず絶対URIを指定する必要がありました。{{ Bug(323455) }} を参照してください。
{{ Fx_minversion_inline(3) }}
JavaScript コードモジュール を利用する場合、拡張機能やアプリケーションがComponents.utils.import を使用してモジュールを読み込めるようにするために、resource プロトコルのエイリアスを作成する必要があるでしょう。エイリアスは resource
行を使うことによって作られます:
resource エイリアス名 uri/to/files/ [flags]
これは resource://<エイリアス名>/
という URI に対して、与えられたパスへのマッピングを行います。
Web 上のコンテンツを resource URI から読み込むことを防ぐようなセキュリティ上の制限事項は無いことに注意が必要です。ここで何を可視化しようとしているのかについて注意を払ってください。
{{ 英語版章題("Manifest Flags") }}
マニフェストの行は、空白区切りにより複数のフラグを持つことができ、 それらは登録行の最後に追加します。 これらのフラグは、そのパッケージの chrome に特殊な属性をマークしたり、 その行が使用される条件を制限するために使用されます。
{{ 訳語("拡張機能", "Extensions") }}は、複数のアプリケーションに対してインストールされる可能性があります。 特定のアプリケーションだけに適用する 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 application=songbird@songbirdnest.com
{{ 訳語("拡張機能", "Extensions") }}は、アプリケーションの複数のバージョンに対してインストールされる可能性があります。 特定のバージョンだけに適用する chrome 登録行を置きたい場合には、
appversion=version appversion<version appversion<=version appversion>version appversion>=version
のフラグによって、拡張機能が識別されたバージョンのアプリケーションにインストールされる場合にのみ、この命令を適用することを示します。 複数の appversion
フラグを単一の行に含めても構いません。 その場合は、その中のいずれかが一致した場合に適用されることになります。 なお、バージョン文字列は、Toolkit version format に従っている必要があります。
Gecko 1.8.0.13 および 1.8.1.5 以前のバージョンには、比較演算子 <, > または = を使用していてバージョン文字列の中に2つ以上のアルファベットが含まれている場合についてバグがありました。バグを踏んだ場合には、エラーコンソールに appversion
フラグを解釈できなかった旨のメッセージが表示されていました。{{ Bug(380398) }} を参照してください。
{{ Fx_minversion_inline(3) }} chrome のリソースは、信頼されていないソースから読み込まれたページに含まれる、またはそのようなページに挿入された <img>, <script> またはその他の要素から参照できなくなりました。この制限は、信頼できないソースの中で定義された要素と、信頼された拡張機能によって追加された要素のいずれに対しても適用されます。もしそのような参照を明示的に許可する必要がある場合には、古いバージョンのFirefox と同じ結果を得るために、contentaccessible
フラグを yes
と指定してください。詳細は {{ bug(436989) }} を参照してください。
contentaccessible
フラグはコンテントパッケージに対してのみ適用でき、ロケールまたはスキンの登録に対しては無視されます。しかしながら、マッチしたロケールおよびスキンのパッケージは、コンテントパッケージにも露出するでしょう。
注: 古いバージョンの Firefox は contentaccessible
フラグを解釈しないため、 Firefox 3 とそれ以前のバージョンの Firefox の両方に対応するよう設計された拡張機能は、フォールバックのための指定を必要とするでしょう。例:
content packagename chrome/path/ content packagename chrome/path/ contentaccessible=yes
これは {{ bug(292789) }} のため、Firefox 3 RC 1 において変更されました。
{{ Fx_minversion_inline(3) }} 拡張機能(およびテーマ)は、Firefoxが動作しているオペレーティングシステムに依存した異なる機能を提供することができます。値はそのプラットフォームの OS_TARGET の値と比較されます。
os=WINNT os=Darwin
OSの名前のより詳しいリストはOS_TARGETを参照してください。OSの名前は大文字小文字は区別されません。
{{ Fx_minversion_inline(3) }} 拡張機能あるいはテーマは動作しているオペレーティングシステムのバージョンによって異なる挙動を示す必要に迫られることがあります。例えば、あるテーマでMac OS X 10.5(以降)用に、10.4(以前)とは異なる外観を適用したい場合はこのようになります:
osversion>=10.5
{{ Fx_minversion_inline(4) }} コンポーネントが特定の API に対してのみ互換性がある場合、この指定で ABI を記述する事ができます。例:
binary-component abi=WINNT_x86-MSVC
より詳しい情報は XPCOM ABI を参照してください。
パッケージの中には、プラットフォーム固有を示すために専用のフラグでマークされているものがあります。 このようなパッケージでは、コンテント、スキン、ロケールのうちのいくつかのパートが、実行されているプラットフォームによって異なっているために、 「Windows と OS/2」、「Macintosh」、「{{ 訳語("Unix 系", "unix-lile") }}」のプラットフォームのために、3 セットの異なるファイルが含まれることになります。 例えば、ダイアログの「OK」と「キャンセル」ボタンの並び順は、プラットフォームによって異なります。 また同様にいくつかの項目の名前も異なっています。
「platform」{{ 訳語("修飾子", "modifier") }}は、コンテントの登録の場合のみ{{ 訳語("解釈", "parse") }}され、ロケールとスキンの登録では行われません。 しかしながら、このフラグはパッケージの 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
(それ以外の全て) のサブディレクトリを置く必要があります。 これらのサブディレクトリ以外に置かれた任意のファイルは、全て無視されます。
Chrome パッケージでは、{{ 訳語("悪意のある", "malicious") }}コンテンツにアクセスした場合に、それらからパッケージのコードを自動的に保護するために、 セキュリティのメカニズムである XPCNativeWrapper を使用するかどうかを決めることができます。 詳細については、chrome から コンテントの DOM に安全にアクセスする方法を参照してください。
このフラグは Firefox 1.5 以前では初期状態で有効となっており、Firefox 4 までの間は、 xpcnativewrappers=no
と指定することによって手動で無効化することができました。
{{ gecko_callout_heading("2.0") }}
このフラグは Gecko 2.0 {{ geckoRelease("2.0") }} で廃止されたため、XPCNativeWrapper
はどのような方法によっても無効化できなくなりました。このフラグ無しで動作するようにあなたのアドオンを更新するには以下を参考にしてください:
wrappedJSObject
プロパティを参照する必要があるでしょう。xpcnativewrappers フラグは、コンテントパッケージのみに適用され、 ロケールとスキンの登録では識別されません。
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/
プレインテキスト形式のマニフェストの導入 (Firefox 1.5 と Toolkit 1.8 で実施) より前には、"contents.rdf" という名称の RDF によるマニフェストが chrome の登録のために使用されていました。 この形式は{{ 訳語("非推奨", "deprecated") }}です。 しかしながら、バージョン2より前の SeaMonkey は、プレインテキスト形式のマニフェストをまだサポートしていないため、 Firefox 1.0 に対する後方互換性の維持や、Mozilla スイート への対応が必要な拡張機能では、contents.rdf マニフェストが必要になります。
{{ gecko_minversion_note("1.9.2", "contents.rdf
形式のマニフェストファイルは Gecko 1.9.2 以降では利用できなくなりました。この形式を使用しているアドオンであっても、既にインストールされていた物は動作し続けますが、新たにインストールすることはできません。アドオンを削除してインストールし直す際は、プレインテキスト形式のマニフェストを使うようにアドオンが修正されていることを確かめて下さい。") }}
{{ page("en-US/docs/Toolkit_API/Official_References") }}