Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

Setting Up a Development Environment

ツールの入手

ここでは、アドオン開発 (または他の開発にも) に役立つ、ソースコードエディタ、ソースコントロールシステム、ビルドシステムの 3 つの基本的なツールを紹介します。

コードを編集するための公式の Mozilla IDE は存在しません。他方で、拡張機能はウェブ開発と同じ (またはよく似た) 言語を使用しているため、ほとんどのテキストエディタや IDE が開発作業に使えます。ほとんどのオンラインで見つかる XUL ツールやプラグインは、プロジェクトのフォルダ構造を生成するテンプレートでしかありません。これらはあまり役に立たないでしょう。

おすすめのエディタは、Komodo Edit です。これは、フリーでオープンソースであり、クロスプラットフォームで動作します。また、Mozilla XULRunner プラットフォームをベースにしているため、Firefox の拡張機能開発を部分的にサポートしています。Komodo Edit には、XUL タグや属性の入力を自動補完する機能があり、Mozilla の CSS 拡張仕様 ("-moz" で始まる CSS の値やプロパティ) もサポートしています。また、Firefox と似たアドオンシステムを備えており、拡張機能開発に役立つ Komodo の拡張機能もあります。他の多くのエディタよりも多くの拡張機能開発に役立つ機能を備えているため、ぜひ試してみることをお勧めします。このチュートリアルの例は Komodo Edit で扱っているため、ダウンロードしたファイルに .kpf ファイルが含まれていることがあります。これは、Komodo プロジェクトファイルです。

ソースコントロール (バージョン管理システムとも言います) については、適当なものを使用することをお勧めします。私たちは Subversion を使用していますが、他のどのツールでもよいでしょう。このチュートリアルでは、その使用方法を取り上げません。

XPI ファイルにパッケージ化するツールは、make の使用をお勧めします。これは、Mozilla が Firefox のビルドに使用しており、すべてのオペレーティングシステムで利用可能なシステムです。また、make は、ほとんどの UNIX ベースのシステムのデフォルトツールです。Mac OS X には、XCode Tools パッケージの一部としてインストールすることができます。Windows には、cygwin からインストールできます。cygwin インストールの場合は、ダウンロードとインストールを行うパッケージのリストから、makezip ユーティリティにチェックを入れてください。

また、make を実行可能なシステムパス内に置いてください。make のセットアップ後、コマンドラインウィンドウを開き、 "make -ver" コマンドを実行して make のインストールされたバージョンが出力されることを確認してください。

ぜひ、あなたのシステムで make をセットアップしてください。私たちのコードの例には、この make を使用して最終的な XPI ファイルをビルドし、インストールするために必要なすべてのファイルが付属しています。このツールをしようすることで、パッケージ化する時間を節約できます。または、バッチファイルでパッケージ化を行う同等のシステムを作成してもよいでしょう。

ビルドシステム

それでは、前回の練習問題で作成した Hello World の 2 番目のバージョンをビルドするためのプロジェクトをダウンロードしてください。

Hello World 2 プロジェクト

適当な場所にファイルを展開してください。HelloWorld2 ディレクトリ内には、bin and src の 2 個のディレクトリがあります。bin は空のディレクトリです。ここには、ビルド時に作成されたファイルが格納されます。ビルドすると、このディレクトリに拡張機能の XPI ファイルが置かれます。

src ディレクトリ内のプロジェクトファイル (HelloWorld2.kpf) を Komodo Edit で開いてください。Projects タブには、src ディレクトリ内のディレクトリ構造が表示されています。この構造は、前回のセクションで展開した XPI とほとんど同じなので見覚えがあるでしょう。

一つだけ補足すると、src ディレクトリの下に Makefile ファイル、chrome ディレクトリの下に Makefile.in ファイルがあります。これらは、make が XPI のビルドに使用するファイルです。後でこのファイルを読んで理解しなければなりません。また、少なくとも、あなたのプロジェクトに合わせて変更すべき部分を知らなければなりません。make と Makefiles について知るには、GNU Make Manual を参照するとよいでしょう。

多くの場合、変更が必要な個所は Makefile の最初の数行だけです。これらは、拡張機能の名前 (JAR ファイルの名前にも使用されます) と ID (install.rdf 内に指定されます)、開発とテストのために拡張機能をインストールするプロファイルを定義します。これ以上のことは、後で扱います。

はじめに、コマンドラインから XPI をビルドしてみましょう。システムのコマンドラインプログラムを開き、Hello World プロジェクトの src ディレクトリへ移動してください。次のコマンドを実行します:

make

行うことはこれだけです。すべてがうまくいけば、コマンドラインに次のように出力されます:

Creating chrome JAR file.
  adding: content/browserOverlay.js (deflated 42%)
  adding: content/browserOverlay.xul (deflated 59%)
  adding: skin/browserOverlay.css (stored 0%)
  adding: locale/ja/browserOverlay.dtd (deflated 52%)
  adding: locale/ja/browserOverlay.properties (stored 0%)
Creating chrome JAR file. Done!
Creating XPI file.
  adding: install.rdf (deflated 50%)
  adding: chrome.manifest (deflated 60%)
  adding: chrome/xulschoolhello.jar (deflated 30%)
Creating XPI file. Done!

Build finished successfully.

bin ディレクトリを調べてください。ビルドされた xulschoolhello2.xpi ファイルと、プロジェクトファイルのコピーが含まれた build ディレクトリがあるはずです。build ディレクトリは、最終的な XPI がビルドされる前のファイルがコピーされる一時的な場所です。再び make を実行すると、ビルドプロセスの最後の行だけが表示されます。これは、build ディレクトリ内のファイルが最新であるため、make が行う作業がないことを示しています。ソースファイルに変更を加えると、make が XPI ファイルのビルドに必要な作業を再び行います。

次のコマンドを実行 (再び、src から) するだけで、bin ディレクトリを掃除することができます:

make clean

これらのコマンドは Komodo からも実行できます。メニューの Tool > Run Command... をクリックし、"Run:" テキストボックスに次のコマンドを入力します:

bash -c "make"

または、"clean" を追加して clean コマンドを実行します。"bash -c" の部分は、Komodo に bash を使用させます。これは、何らかの理由でデフォルトのコマンドシェルが正しく設定されていない場合に入力します。この部分は必要ではありませんが、次に実行する make コマンドと矛盾しないようにするため、この方法で実行したほうがよいでしょう。

"Run Command" ウィンドウの "More" ボタンをクリックして Advanced Options を表示し、"Start in" テキストボックスに %p (現在のプロジェクトのディレクトリパスを表す) を入力してください。"Add to Toolbox" チェックボックスをクリックしてチェックを入れると、このコマンドを Toolbox に保存できます。Toolbox を表示するには、メニューの View > Tabs > Toolbox をクリックします。これで、作成したコマンドをダブルクリックするだけで簡単に XPI ファイルをビルドできるようになりました。

さらに改善しましょう。一度コードをテストしてデバッグすれば、その後何度も XPI をビルドしてインストールする作業が単調で退屈になってくるでしょう。これが、私たちが "make install" を紹介する理由です。これは、拡張機能がすでに Firefox のプロファイルにインストールされている場合にのみ動作します。また、ここで扱っているプロジェクトのように、アドオンの ID とプロファイルの場所を Makefile に設定する必要があります。この情報は、拡張機能をインストールして既存のインストールされたファイルを上書きする場所として使用されます。"make install" の実行時に Firefox が開いている場合は、変更を適用するために Firefox を再起動してください。XPI ファイルをインストールし直すよりよいでしょう。

プロファイルの場所を正しく設定するために、Mozilla サポートサイトのプロファイルについての記事をお読みください。このトピックについては、このセクションの後で深く掘り下げます。

Windows でないシステム上で "make install" を動作させるには、さらに手順が必要です。インストール処理は、OSTYPE と呼ばれる export されていない環境変数を必要とします。手短に説明すると、コマンドラインから実行したいときは、次のようにする必要があります:

export OSTYPE; make install

Komodo 内のコマンドの場合は、次のように入力します:

bash -c "export OSTYPE; make install"

export コマンドは、"bash -c" を使用しないと正しく動作しないでしょう。

Makefile ファイルでは、アドオンのインストール先のプロファイルフォルダを指定します。これは、profile_dir 変数で設定します (例では "xulschool-dev" プロファイルに設定されています)。あなたのアドオン開発用のプロファイルを作成する時は、簡単なプロファイル名を付け、インストールコマンドに使用するため Makefile に設定してください。

IDL ファイルの構築

拡張機能によっては、特殊な機能を追加するための XPCOM コンポーネントを開発する必要があります。このチュートリアルにも XPCOM についてのセクションがありますが、ここでは、拡張機能をビルドする時に XPCOM がもたらす影響について簡潔に議論します。このセクションは読み飛ばしても構いません。後で、XPCOM の使用が必要になった時に参照してください。

XPCOM インターフェースは、IDL ファイルを使用して定義されます。これは、一つまたは複数のインターフェースの属性やメソッドを定義するテキストファイルです。これらの IDL ファイルは、バイナリ形式にコンパイルされ、XPT ファイルとして拡張機能に含まれます。

IDL ファイルを XPT にコンパイルするには、xpidl と呼ばれるコマンドラインツールが必要です。このツールは、Mozilla Gecko SDK に同梱されています。IDL をコンパイルする必要があるときは、SDK のページから、あなたのシステム用にコンパイルされたバージョンをダウンロードしてください。また、システムの必要要件にも注意してください。あなたのシステムがサポートされていない場合は、ご自身で Mozilla のソースから SDK をビルドしなければなりません。幸運を祈ります。

次に、SDK の環境を整えてください。xpidl.exe (他のシステムでは xpidl) をデフォルトで実行可能なパスに置き、次のように、環境変数 GECKO_SDK を追加して SDK ビルドのパスを設定してください:

export GECKO_SDK=/path/to/your/sdk

私たちのビルドシステムはここからピックアップします。Unix ベースのシステム上の Komodo で動作させるには、ホームディレクトリの .bash_login ファイルに、次のコマンドを追加します。

bash -c ". ~/.bash_login; make"

XPCOM コンポーネントを持つプロジェクトの例は、このチュートリアルの XPCOM のセクションにあります。そこでは、さらに複雑な C++ XPCOM をビルドする方法についても言及しています。

拡張機能への署名

ユーザが安全に拡張機能を使用できるようにするため、拡張機能に署名を追加することができます。署名は、あなたが拡張機能の作者であり、信頼された証明書認証局 (CA) から提供された正当な証明書が使用されていることを検証します。

ユーザにとって注意すべき違いは、XPI のインストールダイアログで拡張機能があなたによって作成されたことが表示され、信頼された拡張機能であることが分かるだけです。ほとんどのユーザが、拡張機能の署名に頼るよりも公式のアドオンサイト (AMO) の方を信頼しているため、拡張機能に署名をすることは一般的ではありません。一方では、巨大な企業が自社の拡張機能に署名をすることが標準的な慣習になっています。

拡張機能に署名できるようにするには、いくつかのライブラリをダウンロードする必要があります。手順に従って、以下のような内容を Makefile に追加してください:

# The directory where the signature sources are located.
signature_dir := signature

# The signing key /certificate file.
signature_extra_files := $(build_dir)/META-INF/manifest.mf \
                         $(build_dir)/META-INF/zigbert.sf
# The signing key /certificate file.
signature_rsa_file = $(build_dir)/META-INF/zigbert.rsa# The signing key /certificate file.
signature_files := $(signature_extra_files) \
                   $(signature_rsa_file)

$(signature_files): $(build_dir) $(xpi_built)
  @signtool -d $(signature_dir) -k $(cert_name) \
  -p $(cert_password) $(build_dir)

あなたのパスワードを Makefiles に記述しないように注意してください。また、証明書の情報は慎重に取り扱わなければなりません。これらは一人の人が扱い、リリースプロセスの最終段階に近いところでのみ行うのが良いでしょう。また、署名有りの開発版ビルドと署名無しのものを区別するため、make signed などの別の make コマンドを使います。

Firefox プロファイルの管理

テスト環境を他のすべてのものと分けておくことは、良い開発の慣習です。不安定な拡張機能が日常的に使用する Firefox のプロファイルを壊してデータが失われることは誰も望ません。テスト用の別の "バージョン" の Firefox を用意しておきましょう。Firefox プロファイルは、このためにあります。

複数の Firefox プロファイルをセットアップする方法については、Mozilla サポートサイトのプロファイルの管理の記事をお読みください。プロファイルは好きな数だけ作成できます。また、これを複数のバージョンの Firefox で使用することもできます。例えば、あなたの拡張機能を Firefox 3.5 と Firefox 3.6 またはローカライズされたバージョンでテストできます。様々なバージョンの Firefox を好きなだけインストールし、それらのバージョンとプロファイルを織り交ぜて使用することができます。

Windows と Linux では、サポート記事に書かれた方法で、あなたが作成したすべてのプロファイルのショートカットを簡単に作成できます。

Mac OS X の開発者に対しては、"ショートカット" をセットアップする別の方法もあります。Automator アプリケーションを開いて ユーティリティ > シェルスクリプトを実行 を選び、テキストボックスにプロファイルを読み込むスクリプトを入力してください:

/Applications/Firefox.app/Contents/MacOS/firefox-bin -no-remote -p MyProfile > /dev/null &

"/dev/null" を適当なファイルに置き換えると、Firefox や他の拡張機能からの dump 出力を得ることができます。行末の & は、Automator が Firefox のセッションが終わるまで待機しないようにします。ワークフローではなく、アプリケーションとして保存してください。簡単にアクセスできるように、これをデスクトップや Dock に保存するとよいでしょう。

また、詳細なエラー情報を得られるように、テスト用のプロファイルの設定をいくつか変更してください。通常、Firefox の エラーコンソール (ツール > エラーコンソール) には、ウェブページの JavaScript エラーが表示されますが、設定を変更することによって、あなたの拡張機能からのエラー情報を得ることもできます。設定方法については、開発用の設定をお読みください。

開発者向けの拡張機能

ウェブ開発やアドオン開発に役立つ、幅広い様々な Firefox の拡張機能があります。これらは、Mozilla Add-ons サイトで探すとよいでしょう。また、開発用拡張機能のリストも参照してください。このセクションでは、その中でもとても役立つものを紹介します。

DOM Inspector

DOM Inspector は、以前は Firefox に同梱されていましたが、Firefox 3 からは別のアドオンとして分離されました。これは、HTML や XUL ドキュメントの DOM を調べたいときにとても役に立つ調査ツールです。また、適用された CSS 規則や組み合わされた JavaScript オブジェクトも調べることができます。使い方は、DOM Inspector 入門のガイドをお読みください。

DOM inspector は、ウィンドウのオーバーレイを適用する場所やデフォルトの CSS スタイル規則を置き換える方法を見つけるときに、特に役立ちます。対象のファイル名を知りたいときは、Mozilla のソースコードから調べてください。また、完全に信頼できるものではありませんが、スタイルと属性の変更や JavaScript のコードの実行もできます。

JavaScript Debugger

名前の通りのデバッガです。Venkman JavaScript Debugger は、JavaScript コードの実行をトレースできる素晴らしいツールです。

拡張機能やブラウザのコードをデバッグするには、Loaded Scripts パネルで右クリックし、Exclude Browser Files のチェックを外します。読み込まれたスクリプトのリストは、Firefox のすべてのスクリプトを含むため、とても長くなります。ここで、ファイルに区別しやすい名前を付けたことが役立ってきます。Venkman は、ブレークポイントの設定、メソッドのステップインとステップアプト、JavaScript 実行からプロファイリング情報を得ることができます。また、変数を調べたり、式を監視し続けたり、実行中の任意の地点で JavaScript を評価したりできます。

この拡張機能はほとんどメンテナンスされていないため、バグが多くあります。JavaScript の XPCOM や XBL ファイルのコードのデバッグは特に信頼できません。それにも係わらず、特定の機能が正しく動作しない原因を見つけたいときには真価を発揮するツールです。

Tamper Data

Tamper Data は、HTTP リクエストとその応答を傍受します。リクエストと応答をキャンセルし、それらが送信される前にペイロードデータを置き換えることができます。他にも Live HTTP Headers のような似たツールがありますが、Tamper Data は、私たちが最もよく使用するツールの一つです。後で、HTTP デバッグについても取り上げます。

Firebug

Firebug 拡張には、これまで挙げてきたほとんどすべてのツールが含まれていますが、それらはウェブ開発に焦点が当てられていました。Chromebug 拡張を追加すれば、Firefox が拡張機能開発にさらに役立つものになるでしょう。しかし、これまで挙げてきたアドオンを置き換えるには十分ではありません。

一方で、Firebug はとても親しみやすく、ユーザインターフェースが統合され、より開発者向けであることが分かるでしょう。ぜひ試してみてください。

Leak Monitor

メモリリークは常に、Firefox に対する大きな非難の的になっています。Mozilla は、時間をかけて真剣にメモリ使用量を検証し、また、いくつかのクリティカルな領域でパフォーマンスを改善し、あらゆる種類のメモリリークを取り除いてきました。

しかしながら、拡張機能もメモリリークの原因になっています。Mozilla Add-ons のサイトで拡張機能を公開したい場合は、メモリリークを無くしておくべきでしょう。Using XPCOM in JavaScriptの、メモリリークを避けるためのガイドラインに従ってください。開発者が最も犯しがちな誤りの一つは、JavaScript のイベントリスナやオブザーバを登録して、それらを削除しないことです。削除するコードを常に含める簡単なことを習慣にするだけで、大きな違いが生まれます。

あなたの拡張機能がメモリリークを起こさないようにするため、Leak Monitor 拡張を使用してテストしてください。いつでも、ウィンドウを開いたり閉じたりしてテストしてください。メモリリークは、大抵この操作をした時に表面化してきます。

練習問題

  • XUL School 用の新しい Firefox プロファイルをセットアップしてください。普段使用している Firefox のウィンドウを閉じることなく、XUL School の Firefox を開いたり閉じたりできるようにしてください (もちろん、Firefox を使用していますね?)。XUL School プロジェクトに何か変更を加え、makemake install を行い、変更を加えた拡張機能が動作することを確認してください。
  • DOM Inspector をインストールしてください。このプロジェクトで追加したメニューの場所を見つけてください。Firefox によってデフォルトで適用されている CSS 規則を調べてください。最後に、メニュー項目の計算された CSS スタイルを見てください。Firefox の DOM の残りの部分を見て回り、そのノードが Firefox の UI の該当する部分を見つけてください。
  • JavaScript Debugger をインストールしてください。hello world 関数にブレークポイントを設定して実行してください。スコープ内で利用可能な変数を調べてください。ウィンドウ右側のコンソールで JavaScript コードを実行してください。
  • Tamper Data 拡張をインストールしてください。Tamper Data ウィンドウを開いてから Gmail や Facebook などの AJAX が多用されたページを開いてください (Start Tamper ボタンをクリックしてはいけません。この練習問題では使用しません)。送信されたリクエストによって何が起こっているかを特定してみてください。

以上で、あなたのプロジェクトをすばやく監視し、変更をテストする方法が分かりました。次回は、オーバーレイや新しいウィンドウを通して Firefox に新しい UI 要素を追加する方法を学びます。

This tutorial was kindly donated to Mozilla by Appcoast.Se

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

 このページの貢献者: teoli, ethertank, Marsf
 最終更新者: teoli,