WebExtensionsのコンセプト
MozillaがThe Future of Developing Firefox Add-ons | Mozilla Add-ons Blog（和訳）において、新しい拡張機能APIセットのWebExtensionsを正式に発表した。前記事で紹介したとおり、Blink互換のAPIが採用されている。
発表によれば、WebExtensionsの名称には、アドオン開発をWeb開発に近づけたいというMozillaの思いが込められているらしい。挙動が標準仕様化されることで、同じコードが複数のブラウザ上で動作するとともに、複数のベンダーから幅広くドキュメントが提供される状態。Mozillaは、そうしたWeb開発の理想状態をアドオン開発においても実現することを目指す。上記発表によれば、Chrome／Opera向けの拡張機能や、おそらく将来的にはMicrosoft Edge向けの拡張機能が、わずかな変更でWebExtensionとしてFirefox上で動作するとのこと。前記事で推測したように、やはりMicrosoft EdgeがサポートするFirefoxの拡張機能は、WebExtensionsベースのものを指すようだ。
WebExtensionsには、Firefoxのマルチプロセス化（Electrolysis：e10s）に伴うアドオンの移行手段という側面もある。Add-on SDKに移行することによってもアドオンがe10sに対応することは可能だし、そもそもMozillaがCPOWs（Cross-Process Object Wrappers）と呼ばれる仕組みを導入して、シングルプロセス時に似せた互換環境を用意している。もっとも、前者はrequire(‘chrome’)に加えてXUL要素へのアクセスを提供する一部の低レベルAPIも利用しないとの条件が付くし、後者は本体のパフォーマンスに悪影響を与え、互換性にも限度があるため、リリース版（早ければ2015年12月15日リリース予定のFirefox 43）でe10sが有効化されてから6～12か月を経過した時点で廃止される計画となっている。つまり、アドオンがe10sに対応する手段としては、WebExtensionsを利用するのが最も安全だ。
アドオンの署名義務化を近日中に控え、WebExtensionsベースのアドオンは基本的にMozilla Add-ons（AMO）での公開が想定される。この点について、上記発表は、WebExtensionsベースのアドオンに対するレビュー期間が短縮される見込みだとしている。発表内ではやや曖昧になっているが、AMO review timesを見ると、AMOの平均レビュー期間は延びる傾向にあり、最近はその期間がフル／アップデートともに10週にも及ぶ。これに対し、WebExtensionsベースのものであれば、フルレビューの期間を5日に、アップデートレビューの期間を1、2日にできるという。
なお、WebExtensionsは、デスクトップ版よりも遅れるものの、Android版Firefoxでもサポートされる。
旧APIの廃止に向けた動きと互換性を維持するための方策
MozillaがWebExtensionsを導入する背景には、旧来型のアドオンの仕組みがFirefox開発の足枷になっているという実情がある。アドオンがFirefoxの内部実装に対する完全なアクセスを許されている現在の状況を、Mozillaは放任的アドオンモデル（permissive add-on model）と呼んでいるが、こうしたモデルを維持したままでは、e10sやServoといった新技術の導入に支障をきたすばかりか、Firefoxの開発を遅らせ、クラッシュの原因ともなる。
そこで、Mozillaは、今後12～18か月以内に、XUL／XPCOM／XBLを利用するアドオンを非推奨とする。また、Add-on SDKは開発が継続されるようだが、require(‘chrome’)に加えてXUL要素へのアクセスを提供する一部の低レベルAPIもサポートの対象から外れるようだ。これらの措置により、事実上、既存のすべてのアドオンに何らかの影響が及ぶことになる。
影響範囲の大きさはMozillaも重々承知しており、Firefox Add-on Changes | Bill McCloskey's Blogによれば、以下の有名なアドオンを念頭に置いてWebExtensionsのAPIを拡充していく。
- Tree Style Tab（ツリー型タブ）
- NoScript
- Vimperator／Pentadactyl
- Tab Mix Plus
- FireGestures
- Classic Theme Restorer
このことからもわかるように、WebExtensionsはChromeが提供する拡張機能APIの単なるクローンではない。開発コミュニティからのフィードバック次第で各種のAPIが追加されることもあり得る。また、WebExtensions/Future - MozillaWikiを見ると、アドオンがFirefoxのUIを操作しやすいように、Firefoxのフロントエンドコードに多数の「拡張ポイント」を含めるという話も出ている。
とはいえ、既存のアドオンがほぼ何でもできたことに比べると、WebExtensionsが制限的な機能しか提供できない点は否めない。高機能なアドオン向けに特別の権限（"superpowers"）を付与する仕組みが、過渡的にせよ必要だろう。
MozillaのBill McCloskey氏は、前述のブログ記事で、NoScriptの作者であるGiorgio Maone氏と協力して、そのような特別の権限を付与する仕組みを検討中である旨を明らかにしている。検討内容の骨子は上記のMozillaWiki記事において示されているが、Maone氏が提案するnative.js（仮称）は、有力な選択肢の1つとみられる（hackademix.net » WebExtensions API & NoScript参照）。
Proposal: native.js to "embrace & extend" the WebExtensions API - Add-ons / Development - Mozilla Discourseによれば、native.jsはWebExtensionsベースのアドオンのパッケージ内に含まれ、起動時にchrome権限で実行される。WebExtensionsベースの拡張機能は、native.jsを通じてXUL／XPCOM APIを利用できるというわけだ。もちろん、特別な権限を要求するだけに、AMOのレビューも慎重さが欠かせない。通常よりもレビューに日数を要することになるだろう。加えて、アドオン作者はFirefoxの内部実装における変更を自ら把握して、アドオンの互換性の維持に努めねばならない。
コミュニティの反応
容易に予想できることだが、Mozillaの上記発表は大きな反響を巻き起こした。本記事執筆時点で、発表記事には140件を超えるコメントが付いているが、大半が否定的な反応だ。WebExtensionsの新APIについて提案するフォーラム（WebExtension API Ideas）でさえ、WebExtensionsの採用自体をとりやめるか、Firefoxをフォークせよとの意見が上位を占めるありさまだ。
アドオン作者からの反応も厳しいものがある。CCK2 Wizardの作者Mike Kaply氏は、My Take on WebExtensions | Mike's Musingsの中で、今後WebExtensions APIがどれほど整備されても、手間や時間を考えれば新APIへの移行は進まないだろうと述べている。現に、RSS Tickerなどの作者Christopher Finke氏は、今回の発表を受けてすべてのアドオンの開発を中止した。また、DownThemAll!の作者の一人（匿名）も、今回の発表はただただ悲しい、古い親友のFirefoxが死にそうだと知ったときのようだ、と述べている。
MozillaがWebExtensionsを撤回することはおそらくないだろうが、開発コミュニティからのフィードバックを受けて、XUL／XPCOM／XBLを利用するアドオンを非推奨とする時期が後ろにずれる可能性はありそうだ。
（17/02/12追記）
本記事執筆後に動きがあり、本文の内容は最新ではない。デスクトップ版Firefox 57で拡張機能はWebExtensionsベースに限定化 - Mozilla Fluxを参照してほしい。
