読者です 読者をやめる 読者になる 読者になる

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

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

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

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

  • UI 周りの処理は、以下の 2 通りのどちらかの方法で行う
  • UI 周りに関するではなく本質的な処理は全て JavaScript コードモジュールで行う

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

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

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

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

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