アドオンの Firefox 4 対応に関する最新情報

[これは Mozilla Add-ons Blog の記事 Making your add-on compatible with Firefox 4 の翻訳です。文中でリンクされている MDC の資料に関して、一部のページは日本語化されていますが、必ずしも最新の情報に更新されていないため、英語のページにリンクしています]

先週 Firefox 4 Beta 7 が公開されました。アドオン作者の皆さんにとっては、Firefox の次期メジャーリリースに向けて互換性を評価するのに最適な時期です。これは初めての「機能確定」リリースであり、今後 Firefox の UI や API、機能に大幅な変更は行われないということを意味します。バグ修正や安定性の向上を除けば、これが正式公開される Firefox 4 になりますので、これから出るベータ版やリリース候補版 (RC) で何かが壊れるといった心配をせずに、今回のベータ版にあなたのアドオンを対応させられるはずです。Firefox 4 のリリースは近づいています！ アドオンの互換性を確保したいなら、今がそのタイミングです。

リリースの状況を把握するには？ひとつの方法は、最新のベータ版をダウンロードして、定期的に更新を確認することです。通常、新しいベータ版は数週間ごとに公開されます。また MozillaWiki の Releases ページを時折チェックしても良いでしょう。それから、Mozilla Blog [もしくは Mozilla Japan ブログ] を購読すれば、Firefox 4 関連の最新情報を入手できます。

このブログ記事では、以前投稿した 2 つの記事 (パート 1、パート 2) で言及したものを含め、筆者 [Jorge Villalobos] が把握している、Firefox 4 に入った最新の変更点をすべて取り上げたいと思います。Firefox 4 は、コードと API の変更という観点から見ると過去最大のリリースですので、あなたのアドオンにも影響することがあるかもしれません。この一覧は筆者が知る限り完全な内容となっています。アドオン作者にとってできる限り更新を簡単にすること、それによってエンドユーザが Firefox をアップグレードすべきか否か悩まないようにすることが、この記事を公開する目的です。

アドオンのパッケージと開発環境

Firefox のパフォーマンスを向上させるため、起動時のファイルの読み込みと処理を改善する様々な取り組みが行われています。これにはアドオンファイルも含まれるため、アドオン作者が留意すべき変更がいくつかあります。

パッケージされた拡張機能

Firefox 4 は、大半のコードファイルが、Omnijar とも呼ばれる単独の JAR ファイルにパッケージされた状態で配布されます。パッケージからのファイルの読み込みは通常、ファイルシステムから個別に読み込むよりはるかに効率的です。このため、できるだけ多くのファイルをまとめてパッケージすることで、特にモバイルプラットフォームにおいてパフォーマンスが向上します。同じ考えがアドオンにも拡大され、初期設定で展開されることなくプロファイルフォルダへインストールされるようになります。これにより次のような影響があります。

一部のアドオン、特にバイナリコンポーネントやその他のライブラリを含むアドオンは、展開された状態でなければ動作しません。これは、スペルチェック辞書や、検索エンジンあるいはウィンドウアイコンを含むアドオンにも影響します。こうした展開が必要なアドオンは、install.rdf マニフェストに unpack フラグを追加する必要があります。
プロファイルディレクトリから XPI に含まれるファイルを読み込めなくなります。chrome プロトコルもしくは nsIZipReader コンポーネントをつかってそれらを展開するか、それらを生成する別の方法を探してください。どの方法も使えない場合は unpack フラグを使いましょう。
現在のところ、今まで通りプロファイル内にワーキングディレクトリを持てます。拡張機能ローダーは XPI パッケージと展開されていないディレクトリのいずれかをチェックします。ただし、最終版に関しては、展開せずにアドオンがインストールされることを念頭に置くべきです。
また、従来推奨されていた、すべての chrome ファイルをひとつの JAR にパッケージする習慣をやめるよう推奨します。XPI は今後展開されないので、JAR の内包 (パッケージ内パッケージ) はオーバーヘッドを増やすだけです。[訳注: Firefox 3.6 以下でも、JAR の内包を行わずに XPI を作成することは可能でした。つまり Firefox 4 と 3.6 とで同じ XPI パッケージを提供することができます。ただし 3.6 以下では、XPI が展開されてプロファイル内に保存されるため、直接ファイルの読み込みが必要となり、起動時間に多少影響があります。これが従来 JAR の内包が推奨されていた理由です]

キャッシュ

Firefox は、コードやその他のリソースをより積極的にキャッシュするようになりました。開発用プロファイルで常に変更が反映されるようにするには、コマンドラインオプション -purgecaches を付けて Firefox 4 を起動してください。これにより、すべての関連キャッシュが消去され、確実に最新のコードを実行できます。

プロファイルマネージャ

私たちが慣れ親しんできたプロファイルマネージャツールが Firefox から取り除かれようとしています。このような決定に至るまでには長い議論がありました。簡単に言えば、プロファイルマネージャは非常に長い間更新されておらず、機能が欠けており、さらにその一部のコードが起動速度の低下を招いているのです。当然、適切な代替ツールなしに削除されることはありません。Bug 539524 が必要な開発作業のトラッキングバグです。新しいツールは、ランチャースクリプトのように Firefox とは独立して機能し、従来より強固になるよう設計されています。このツールは Firefox 4 のリリーススケジュールに縛られていないため、完成はリリース後になる可能性があります。もちろん、当面はいつでも Firefox 3.6 のプロファイルマネージャを利用できます。

拡張機能のグローバルインストール

コマンドラインオプション -install-global-extension と -install-global-theme は削除されました。グローバルインストールは常に扱いにくい課題となってきましたが、ユーザを尊重しつつこれを解決する手段についての議論が将来きっと行われることでしょう。アドオンを自動的にインストールする代わりの方法は、MDC の記事 Installing extensions を参照してください。

XPCOM

XPCOM の登録

今後、コンポーネントは chrome.manifest ファイルに明記する必要があります。これにはバイナリコンポーネントも含まれます。様々な起動オブザーバトピックが、唯一の例外 profile-after-change を残して削除されました。リスナーとカテゴリ登録もマニフェスト内で宣言する必要があり、このため、一部のカテゴリ名が変更されました。詳しくは MDC の記事 XPCOM Changes in Gecko 2.0 をご覧ください。

その他 XPCOM 関連の変更

xpcnativewrappers=no は削除されます。この手法は常に安全でないと考えられており、それに対するより安全な代替策が提供されています。

新しい Gecko SDK はまだ公開されていません。バイナリ XPCOM を使う開発者はソースから自分でビルドする必要があります。ベータ版のソースコードは FTP サイトから入手可能です。

古くて廃止予定だった nsIPref インタフェースが削除されました。推奨されている nsIPrefService もしくは FUEL ライブラリを使っている場合には影響ありません。

UI

ツールバー

ツールバーボタンはいくつかの異なるサイズを用意する必要があります。以下が主要プラットフォーム向けの最新アイコンセットです。

Windows: アイコンは 18×18 px です。非常にシンプルなスタイルで作られており、Aero の有効、無効に関わらず、同じように表示されます。
Mac OS X: アイコンは 20×20 px です。今まで通りシンプルですが、今回のアイコンには周囲のボタンスタイルが含まれておらず、他のプラットフォームと一貫性が保たれています。
Linux: アイコンは 24×24 px です。今まで通り、テーマはほぼ GNOME アイコンに依存します。

これは 3.6 のアイコンからの抜本的な変更となります。Linux だけ同じアイコンとアイコンサイズが採用されていますが、自動リサイズに頼りたいのでなければ (そうすべきではありません) Firefox 4 のために新しいツールバーアイコンを作成する必要があります。幸い、クロームマニフェストファイルでは、OS とアプリケーションのバージョンに応じて簡単にスキンを分割できる、いくつかの便利なフラグを使うことができます。

また、あなたのアドオンがオーバーレイで新しいツールバーを追加している場合、そのツールバーが表示されない問題に気付くかもしれません。これは、toolbox 要素のオーバーレイが、overlay 要素の直接の子要素ではなく、window 要素の子要素となっているときに発生します。ノードを移動すれば問題を解決できます。

Firefox アプリケーションメニュー

Windows 版の Firefox 4 では、メインメニュー (ファイル、編集、表示など) が初期状態で非表示となります。代わりに、簡素化された Firefox アプリケーションメニューを開くボタンがひとつ置かれます。このメニューにはよく使われるメニュー機能がまとめられており、ユーザの利便性を向上させます。従来の「クラシック」スタイルのメニューは、Alt キーを押すことで、表示、非表示を切り換えられます。

あなたのアドオンがメインメニューからしか見つけられない場合、アプリケーションメニューに対してもオーバーレイしたいと思うでしょう。拡張機能のメニュー項目専用の場所は用意されていないので、メニューを調べて、あなたのアドオンに最適な場所を見つけてから、オーバーレイ内で指定する正しい ID を特定する必要があります。

ステータスバー

ステータスバーは削除され、アドオンバーに置き換えられました。

初期状態では、ブラウザウィンドウの下部には一切クローム要素がありません。アドオンによってアイコンなどがアドオンパーに追加されると、従来のステータスバーと同じ場所に似たようなスタイルで現れます。アドオンバーは本来のツールバーであるというメリットを持ち、将来的には (Firefox 4 には間に合わないかもしれませんが) ユーザによるカスタマイズも可能になります。逆に初期状態では非表示になっているというデメリットがあり、また従来より幅を取るため、そこに項目を追加するアドオンはあまりユーザに歓迎されない可能性もあります。

後方互換性を確保するため、従来のステータスバーはアドオンバーへ完全に内包される形となりました。このため、あなたのアドオンがステータスバーに何かをオーバーレイしている場合も、今まで通り動作します。これは過渡的な措置に過ぎませんので、なるべく早めにステータスバーからボタンを外し、アドオンバーへ移動してください。

タブ

Beta 4 で Firefox Panorama (旧称 Tab Candy) と呼ばれる機能が投入されました。これは大きな新機能であり、Firefox 内でタブを見渡して管理する新しい方法です。しかし残念ながら、Firefox のタブ関連コードに行われた変更によって、一部のタブ管理系アドオンが機能しなくなる可能性があります。タブバーには、Panorama を表示させる新しいボタンがあり、タブのコンテキストメニュー項目も追加されています。

タブは初期状態でウィンドウ最上部に表示されるようになりました。タブバーとツールバーの位置を入れ替えるための設定があります。

Firefox 4 では、普通のタブをアプリケーションタブへ切り替えられるようになりました。基本的にこれらのタブは簡単に閉じられないようになっており、タイトルは隠され、favicon だけが表示されます。

アドオンマネージャ

Firefox 4 には、全面的に刷新されたアドオンマネージャが搭載され、別ウィンドウで開かれる代わりに新しいタブで展開されます。アドオンの情報を表示できる部分が広がり、アイコン用のスペースは 64×64 px まで拡大されました。従来の 32×32 px のアイコンでも見た目は問題ありませんが (自動的には拡大されません)、作者の皆さんはおそらく対応したいと思うでしょう。32×32 px へ縮小した場合は見た目が損なわれないため、後方互換性についてさほど気にすることなく大きなアイコンを含められます。

アドオンマネージャのバックエンドも刷新されました。nsIExtensionManager インタフェースは、その RDF ストレージとともに削除されました。アドオンのメタデータは SQLite データベースに保存されるようになり、アドオンマネージャは AddonManager という JavaScript モジュールになりました。この新インタフェースの主な違いは、アドオンメタデータの取得が非同期で行われるようになったことです。これは FUEL ライブラリにも当てはまり、アドオンデータを取得しているすべてのアドオンに影響します。起動時にデータを取得し処理しているアドオンにとっては特に難しい問題です。ただ、起動時のパフォーマンスを向上させるための推奨事項にも従おうとしている場合は、いずれにしても非同期で行う起動処理の実装を検討すべきでしょう。

XUL とオーバーレイ

タブ周りの DOM とその内部のブラウザ要素に変更が加えられ、よりオーバーレイしやすくなりました。しかし、これによって、例えばタブに関連付けられた notificationbox へアクセスする際など、あなたの書いたコードが parentNode を使って DOM を参照している場合、そのコードは動作しなくなる可能性があります。gBrowser オブジェクトとその関連オブジェクトによって、それらのノードへアクセスするための便利なメソッドが提供されていますので、これはいずれにしても採用すべきでない方法です。

TabClose、TabSelect、TabOpen の各イベントは、tabbrowser 要素、つまり gBrowser まで浮上しなくなりました。これらのイベントを監視するイベントリスナーは gBrowser.tabContainer へ追加してください。

リモート XUL

リモート XUL は、開発者が HTML の代わりに (あるいは HTML とともに) XUL と XBL を使って Web サイトを作成できるようにする、Gecko ブラウザでもめったに利用されない機能です。XUL に対応しているブラウザは限られることから、XUL を使って Web サイトを作成する理由はほとんど見当たりません。しかしながら、社内だけで利用される様々な業務アプリケーション (「XUL の暗黒物質」とも呼ばれます)、さらに一部の公開サイトにおいて、うまく活用されてきました。

リモート XUL は大きなメンテナンスの問題を抱えており、多数のバグやセキュリティ脆弱性の原因となってきました。このため、Firefox 4 でリモート XUL は削除されます。幸い、HTML5 には既に十分強固なボックスモデルが含まれていますので、ここでの主な損失を挙げるとするなら、Web 開発者が今後 Web ページ上で XBL を利用できなくなることでしょう。これは、場合によってはアドオンのみならず、XUL を (リモートの) HTML ページへ挿入できなくなるということでもあります。iframe や XBL バインディングなどで、コードが chrome URL から読み込まれる場合は、今まで通り動作します。

簡単に言えば、リモートサイトからの XUL コンテンツは、ローカルの file プロトコルを使った場合でさえも読み込めなくなります。しかし、すべてが失われたわけではありません。XUL から他の技術への過渡期として、リモート XUL 対応は完全に削除されたわけではなく、無効化されただけなのです。特定のサイトで XUL や XBL を使えるようにするため、個別ドメインを指定できるホワイトリスト機能が提供されています。なお、このホワイトリストを編集できる UI はありませんので、筆者はその穴埋めとして Remote XUL Manager というアドオンを作成しました。これを使えば簡単にホワイトリストを管理できるはずです。

その他の変更点

JavaScript オブジェクトをスレッド間で受け渡しできなくなり、アドオン作者にとってスレッドマネージャはまったく使いものにならなくなりました。これは土壇場での修正であり、影響を受ける開発者はおそらくごくわずかですが、現時点で利用できる代替策が少ないことから大きなインパクトをもたらすでしょう。ChromeWorker インタフェースを改良する議論があり、それが適当な代替策となりますが、今後のベータ版で採用されるかどうかはまだ不透明です。
プライバシー上の理由からユーザエージェント (UA) 文字列が最小化されました。こうした取り組みに合わせて、Mozilla Add-ons サイト (AMO) ではエディタが拡張機能内での UA 操作をチェックし、不要な変更を禁止します。あなたのアドオンが本当に UA を変更する必要がないなら、そのようなコードは削除してください。
Windows 版でテーマの開発に影響するバグがひとつあり、タイトルバーの近くに黒いボックスが現れる問題を引き起こします。この MozillaZine Forums のスレッドでいくつかの回避策が説明されています。
末尾にカンマが付いた JSON 文字列は、今後 SpiderMonkey の JSON パーサでは受け入れられません。
ネットワークリダイレクト API に変更が加えられ、非同期化されました。これは net-channel-event-sinks カテゴリに登録している拡張機能に影響するもので、すべてのリダイレクトが動作しなくなります。
サイドバーへの URL がドロップされたとき、その URL が開かれるよう、初期状態の挙動が設定されました。あなたのアドオンでサイドバーへのドラッグ＆ドロップを扱っている場合は preventDefault を使うようにしてください。
Firefox 4 は、Mac では 32 ビットと 64 ビットの Intel アーキテクチャに対応し、PPC への対応を打ち切ります。対応プラットフォームの一覧を参照してください。

資料とサポート

Mozilla Add-ons チームでは、開発者の皆さんが最初から必要な情報をすべて入手できるよう、Firefox 4 に関する資料をできるだけ多く公開していこうと考えています。MDC の記事 Firefox 4 for Developers は、最新の API の変更を含めて、Firefox 4 のあらゆる新機能や変更点を網羅した公式文書です。ただ、このブログ記事では、MDC には載っていないことにも多く触れています。筆者は自分が知りうる限りあらゆることを取り上げようと努力しました。もし他に変更があった場合や、リリースプロセスの途中で見つかった場合は、このブログ [Mozilla Add-ons Blog] でお知らせします。

筆者が見逃していると思われることがあったり、Firefox 4 の互換性について議論したいときは、Add-ons Forum のこのスレッドが最適な場所です。また、マンツーマンで直接、開発に関するサポートを受けたいときは、IRC チャンネル #extdev に参加することもできます。筆者は普段このチャンネルに常駐していますが、進んで手伝ってくれる経験豊かな開発者が他にもたくさんいます。まずはチャンネルに参加して質問を投げかけてみてください。[日本語で質問したいときは、この modest の Google グループを活用できます]

最後に、もしあなたのアドオンが AMO の「おすすめのアドオン」になっている、あるいは「おすすめ」される資格を得たい場合、その要件を満たすには、Firefox 4 RC 1 のリリース以降、最新版との互換性を保つ必要があることを考慮すべきです。RC 1 は 2011 年 1 月に公開予定ですので、それに沿って作業計画を立ててください。

Happy coding!