mozilla
Your Search Results

    Chrome Registration

     

    Chrome (クロム) とは?

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

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

    Gecko 2.0 note
    (Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1)

    Gecko 1.9.2 およびそれ以前では、Mozilla はアプリケーションのルートから見て chrome/*.manifest の位置にあるマニフェストファイルも読み込みます。Gecko 2.0 (Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1) 以降では、ルートに置かれた chrome.manifest だけがマニフェストファイルとして利用されますが、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
    

    警告: パッケージ名に大文字と小文字が両方含まれている場合、Firefox 2, ThunderBird 2, および SeaMonkey 1.1 は chrome を認識しません。もし上記の例のパッケージ名の箇所が CamelCasePackage のようになっている場合には、\"chrome://camelcasepackage/path/to/files に対する chrome が登録されていません\" のようなエラーメッセージが表示されるでしょう。Firefox 3, ThunderBird 3, および SeaMonkey 2 は大文字と小文字を両方含むパッケージ名に対応しています。このバグは Mozilla 1.9 で修正されました。Bug 132183 を参照してください。

    マニフェスト命令 (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 レジストリは、利用者の設定に最もふさわしいロケールを選択して利用することになります。

    【訳注: 日本語の場合のロケール名について】

    Firefox 1.5 以上は上位互換性を持っており、ja であろうが ja-JP であろうが問題なく動作します。 但し、*.manifest は ja/ja-JP-mac 世代の製品でしか使いませんから、contents.rdf でどうするかにかかわらず、ja を使用することを推奨します。

    Firefox/Thunderbird 1.5 以降での locale の選択は

    1. general.useragenet.locale に完全一致するものがあればそれを使用
    2. 完全一致ではないが言語コードが一致するものがあればそれを使用
    3. 言語コードが一致するものがなければ en-US を使用

    という規則になっているので、拡張機能側では ja でも ja-JP でも好きな方を指定して動作上問題ありません。 Firefox/Thunderbird 1.5 以降しかサポートしないのに ja-JP を指定するというのはナンセンスですので推奨しませんが、Firefox/Thunderbird 1.0.x や Seamonkey 1.0.x などもサポートするのであれば ja でも ja-JP でも構いません。

    Mozilla L10N フォーラムの記事 から引用

    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 [フラグ]
    

    この機能はChrome URIのスタイルシートについてだけ利用できることに注意してください。

    override

    拡張機能や 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を指定する必要がありました。バグ 323455 を参照してください。

    resource

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

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

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

    Web 上のコンテンツを 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 application=songbird@songbirdnest.com
    

    appversion

    拡張機能は、アプリケーションの複数のバージョンに対してインストールされる可能性があります。 特定のバージョンだけに適用する 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 フラグを解釈できなかった旨のメッセージが表示されていました。バグ 380398 を参照してください。

    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 と指定することによって手動で無効化することができました。

    Gecko 2.0 note
    (Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1)

    このフラグは Gecko 2.0 (Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1) で廃止されたため、XPCNativeWrapper はどのような方法によっても無効化できなくなりました。このフラグ無しで動作するようにあなたのアドオンを更新するには以下を参考にしてください:

    • あなたのアドオンがコンテンツ領域のオブジェクトに適用された XBL のバインディングに依存している場合(XBL のバインディングによって追加された関数を呼んだりプロパティの値を取得・設定したりするためにはそうする必要がありました)、生のオブジェクトに触るためにそのオブジェクトの wrappedJSObject プロパティを参照する必要があるでしょう。
    • Web ページの中で定義された関数を呼び出したりプロパティにアクセスしたりする必要がある場合 -- 例えば、あなたのアドオンで Web ページの中で定義された JavaScript の関数を呼ぶボタンを追加したい場合。

    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 マニフェストが必要になります。

    Gecko 1.9.2 note
    contents.rdf 形式のマニフェストファイルは Gecko 1.9.2 以降では利用できなくなりました。この形式を使用しているアドオンであっても、既にインストールされていた物は動作し続けますが、新たにインストールすることはできません。アドオンを削除してインストールし直す際は、プレインテキスト形式のマニフェストを使うようにアドオンが修正されていることを確かめて下さい。

    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!

    ドキュメントのタグと貢献者

    タグ: 
    Contributors to this page: meniv, Morishoji, Gomita, teoli, Shimono, Marsf, Verruckt, Mgjbot, Piro, Okome
    最終更新者: teoli,