Mozilla Flux

Mozilla関係の情報に特化したブログです。

Firefoxでレガシーなアドオンが使えるのは2017年11月半ばまで

窓の杜で既報だが、The Road to Firefox 57 – Compatibility Milestones | Mozilla Add-ons BlogでWebExtensionsへの移行プランが発表された。周辺情報も交えつつ解説しよう。

まず、今回の移行プランでは、WebExtensions限定化の時期がFirefox 57のリリース時(2017年11月14日:米国時間)であることが改めて確認された。昨年11月の発表以来、影響の甚大さゆえに先送りされるのではとの噂が絶えなかったが、Mozillaはそうした観測を否定した。

また、レガシーなアドオンの定義や、移行対象のプラットフォームが明確化された点も見逃せない。XUL/XPCOMベースやAdd-on SDKベースの拡張機能だけでなく、埋め込み型WebExtensionsと完全テーマもレガシーなアドオンに含まれる。ここに埋め込み型WebExtensionsが含まれるということは、Firefox 57以降、WebExtensions APIのみで構築された拡張機能しか動作が許されないことを意味する。そして、プラットフォームの面では、Thunderbird/SeaMonkey向けのアドオンが対象外であると明言された。逆に言えば、Android版FirefoxはWebExtensions限定化の影響を受けるわけだ。

マルチプロセス化(e10s)との関係

最近のFirefoxは、バージョンアップごとにマルチプロセス機能(e10s)が有効化される範囲を拡大してきている。拡張機能の互換性はe10sの有効・無効を決めるうえで大きな要素だ。Firefox 50の時点では、WebExtensionsベースの拡張機能のほか、作者がe10sと互換性あり(MPC=true)に設定した拡張機能がインストールされている場合にだけ、e10sが有効化されるようになっていたが、Firefox 51になって、ホワイトリストに掲載された700を優に超える拡張機能(Firefox Beta版でのテストを経て問題なしと判断されたもの)も、e10s有効化の妨げにならなくなった(Bug 1329015)。Firefox 52もほぼ同じ基準になるようだ。

移行プランにおけるFirefox 53のリリース時(2017年4月18日:米国時間)の記載は、こうした経過を踏まえたものである。Firefox 53では、作者がe10sと互換性なし(MPC=false)に設定しない限り、e10sは有効化されるのが原則。例外的に、Mozillaが互換性に問題ありと判断した拡張機能がインストールされているとe10sを無効化する。

e10sの原則有効化と歩調を合わせるようにして、Mozilla Add-ons(AMO)ではレガシーアドオンの新規投稿を受け付けなくなる。既存のレガシーアドオンの更新は可能だが、野良アドオンにデジタル署名を付すことができなくなるとみられ、少なからず影響が出そうだ。

WebExtensionsの別プロセス化

移行プランでは、Firefox 54から56までに関する言及は少ない。Firefox本体のcontentプロセスの複数化(e10s-multi)とサンドボックス化の進展によって、レガシーなアドオンに互換性の問題が生じるかもしれないと記載されているのみだ。

だが、この間にWebExtensionsベースの拡張機能はFirefox本体のプロセスから独立して動作するようになる可能性が高い(Bug 1190679)。この拡張機能専用プロセスは、本体よりも強固なサンドボックス化が施される予定である(Bug 1334557)。ただ、Chromeのように拡張機能ごとにプロセスを割り当てることまではしない。

WebExtensions限定化

Firefox 57のリリース時にWebExtensions限定化の措置が執られた後も、AMOではレガシーなアドオンの掲載を続け、作者が更新できるようにする。掲載をいつまで続けるかは現在のところ未定だ。

WebExtensions限定化の措置はNightlyチャンネルから順に投入されていくため、Firefox Nightly 57のユーザーは、より早い段階で措置の影響を受ける。もっとも、Nightly/Auroraチャンネルに関しては、レガシーなアドオンをインストール可能にする設定が導入される可能性が高い。Nightly/Auroraチャンネルにはアドオンのデジタル署名チェックを回避する設定もあるため、AMOからレガシーなアドオンが排除された後も、Firefox本体の設定が残っている限り修正版を野良アドオンとして利用することができそうだ。ただ、Firefox本体に搭載されたe10sとの互換性を保つための仕組み(e10s shim)が削除されるため、本当に古い拡張機能はどうしようもない。

最後に、Mozilla Corp.でAdd-ons Developer Relations Leadを務めるJorge Villalobos氏による今回の移行プランに関するコメントを紹介しておく。

I fully admit the timing was bad. The opportunity and resources to launch WebExtensions came up when we were already into the initial e10s migration process, and the plans for Firefox also shifted in a way that WebExtensions can be the only path forward. We can’t support legacy add-ons for 2 years more because the APIs they rely on won’t exist then. Supporting them for longer only means extending the frustration of constant breakage, both for developers and users.

タイミングが悪かったことは完全に認める。WebExtensionsを起ち上げる機会とリソースが出てきたときには、既にe10sへの移行プロセスが始まっていたし、Firefoxの計画も変わって、WebExtensions以外に進める道はない。依存しているAPIがなくなってしまうので、レガシーなアドオンをもう2年サポートしろと言われても無理なんだ。サポート期間を延ばしても、頻繁に動かなくなってフラストレーションが溜まるだけだよ。開発者にとっても、ユーザーにとってもね。