XUL アドオンの JS コードモジュール とロジックの関係

Firefox 拡張の作り方 (2013 年版) - ひだまりソケットは壊れない　という、とっても素敵な記事が出ていたので、個人的な感想と勝手な補足をする次第です。 最近のアドオン開発はそんなに詳しくないんですが、XUL オーバーレイなアドオンに関しては何本か自分でもメンテナンスしているので、簡単に書きます。

JS コードモジュールとロジックの関係

元記事ではXUL ベースのアドオンの開発の際に、

• UI 周りの処理は、以下の 2 通りのどちらかの方法で行う
  • XUL オーバーレイの際に読み込んだ JS で行う
  • JavaScript コードモジュール から、XPCOM コンポーネントを通じて UI 操作を行う
• UI 周りに関するではなく本質的な処理は全て JavaScript コードモジュールで行う

とありますが、JS コードモジュールから頑張って XPCOM を使って ChromeWindow を取得して DOM に触って UI を弄るのはやるべきではないです。やってもいいんですが、面倒くさいです。こんなことやる暇があったら遊びましょう。Mozilla ソースツリー内の UI のテストコードで nsIWindowWatcher を使って現在のウィンドウを取得して QueryInterface して ChromeWindow オブジェクトからDOMに触れるようにしてるケースを見たことはありますが、あくまでもテストケースとしてその方法を使うしか無いからやってるだけだったりします。基本的に、（XULオーバーレイな*1）アドオン開発の場合、そこまでやっても労力に見合わないケースの方が多いです。

Firefox 4 以降の本体でもよく使われている、UI （DOM）操作コードを JS コードモジュールに含めるパターンとしては、

• コンストラクタとプロトタイプ一式を JS コードモジュール内に配置
  • コンストラクタは ChromeWindowを引数に受け取るようにする
  • インスタンスの生成時に、受け取った ChromeWindow をインスタンスと紐づけて管理する
  • DOM に絡む操作は、この紐づけて管理している ChromeWindow 経由で行う
• ウィンドウ側に読み込むスクリプト内では
  • JS コードモジュールのロード
  • ChromeWindow オブジェクトを引数に渡してインスタンスを生成
  • このとき生成したインスタンスは、グローバル変数としてセットする

というのがよく見受けられます。 こうすることで、XPCOM へのアクセス無く、対象ウィンドウの DOM に触れる状態のまま、コードの多くを JS コードモジュール内に移すことが可能になります。 この手法を行うデメリットとしては、

• JS コードモジュールのデバッグは今でこそマシになってきたが色々とやり難い
• インスタンスに紐づけた ChromeWindow の参照保持によるメモリリークの危険がある

あたりですが、前者に関しては仕方ないので諦めてください。 後者については、DOM に触っている関係上、ChromeWindow の unload イベントにイベントリスナを叩き込んでおいて、その中で適切に解放することがだいたいできますし、Firefox であれば WeakMap も使えますし、最悪は Components.utils.getWeakReference() を使用するといった方法もあるにはあるので、こうしたものを使えば何とかなることが多いです。何とかならない時は諦めて JS コードモジュールを使わないようにしましょう。

*1:ブートストラップ型だとそういうことを頑張って行う必要があったと記憶しています