デスクトップ版Firefox 57で拡張機能はWebExtensionsベースに限定化

Mozillaは、Add-ons in 2017 | Mozilla Add-ons Blogにおいて、Firefox 57のリリース（2017年11月28日：米国時間）に伴い、デスクトップ版ではWebExtensionsベースの拡張機能だけを読み込む措置を執る旨を明らかにした。XUL／XPCOMベースやAdd-on SDKベースの拡張機能（レガシー拡張機能）は、一切利用できなくなる。この措置を確実なものとするため、Mozilla Add-ons（AMO）では、Firefox 53のリリース（2017年4月18日：米国時間）に伴い、新規の拡張機能を登録する場合にWebExtensionsベースでないと受け付けなくなる。

現時点でのスケジュールは、Add-ons/2017 - MozillaWikiに詳しい。それによれば、Firefox 53のリリース時点で具体的に実施される措置は、AMOにおいて新規のレガシー拡張機能にデジタル署名を付さないというもの。既存のレガシー拡張機能がバージョンアップした場合は、従前どおり署名が付されるし、Android版Firefox向けやThunderbird／SeaMonkey向けの拡張機能には影響がない。

これがFirefox 57のリリース時点になると、デスクトップ版では本体が読み込むアドオンは次のものに限定されることになる。なお、Android版FirefoxやThunderbird／SeaMonkeyがどうなるかは、現時点で明らかにされていない。

• 署名されたWebExtensions
• 署名されたブートストラップ型システムアドオン
• 言語パック
• 辞書
• OpenSearchプラグイン
• 軽量テーマ

上記のリストを注意深く見れば、完全テーマ（XULベースのもの）が入っていないことに気付くだろう。Mozillaは現在、完全テーマと軽量テーマを統合した新テーマ（Bug 1306671）を開発中であり、この新テーマを実現するAPIはWebExtensionsの一部となる。つまり、新テーマは上記のリストのうち「署名されたWebExtensions」に該当するわけだ。

今からちょうど1年後には、レガシー拡張機能と完全テーマがことごとく機能を停止することになる。そのため、MozillaはこのときまでにChromeが提供する拡張機能向けAPIの大半をFirefoxでサポートしていく。アドオン作者は、既存の拡張機能／テーマをWebExtensionsベースに移植してAMOに登録すれば、自動アップデートによってレガシー版を置き換えることができる。既にEvernote Web Clipperのように実行した例もある。また、Firefox 51で導入される埋め込み型WebExtensionsの仕組みを利用して、レガシー拡張機能に含まれるWebExtensions部分を増やしていき、段階的に移行することも可能だ。

いうまでもなく、今回発表された措置がユーザーに与える影響は甚大である。レガシー拡張機能を使い続けるためFirefox ESR 52に乗り換える手もあるが、こちらも2018年6月中にはサポートが切れる。早めにインストールする拡張機能を整理し、WebExtensionsベースの代替物がないか探すといったことも必要になってきそうだ。

Firefox 50で拡張機能を入れた場合のパフォーマンスが改善

Firefox 50は、当初2016年11月8日（米国時間）に予定されていたリリースが、11月15日に延期されている。リリース直前に大きめの修正（Bug 1309350、Bug 1309351）を入れたので、様子を見る必要があったというのが、延期の理由だ。

この修正により、Add-on SDKベースの拡張機能やモジュールローダを使用する拡張機能について、パフォーマンスが改善される。つまり拡張機能を積んだ環境の多くで、起動時を中心にFirefoxの処理がスピードアップする。そのうえ拡張機能を入れていなくても若干起動が早くなったとか、多数の拡張機能を入れている場合にシャットダウンが大幅に早くなったといった話もある。

MozillaがFirefox 50のリリースを遅らせてまで拡張機能を入れたときのパフォーマンスを引き上げようとしたのはなぜか。それは、Mozillaが最近Test Pilotという新機能の公開テストに力を入れていることと関係する。Test Pilotで公開されている拡張機能は、WebExtensionsではなくAdd-on SDKをベースに作られており、本体の改良がテスト機能の利用状況改善に直結するとの判断があるのだ。

実際に、Activity Streamのような処理の重いTest Pilot向け拡張機能を使っていると、本体の起動や最初の画面表示に要する時間は、Firefox 50で明らかに短縮されているのがわかる。拡張機能側のチューニングでは越えられなかった壁を、やすやすと越えていった感じだ。

使っている拡張機能の種類や数によって効果の現れ方は違うものの、ユーザーにとっては1週間待った甲斐があったといえそうである。

MozillaはQuantumプロジェクトで過去と訣別し、未来に賭ける

次世代のWebエンジンを構築

Mozillaが最近発表したQuantumプロジェクトは、Firefoxのエンジン部分にあたるGeckoを次世代のWebエンジンへと進化させ、パフォーマンスの飛躍的進歩（quantum leap：直訳は量子跳躍）をもたらす*1。Mozilla Corp.でHead of Platform Engineeringを務めるDavid Bryant氏が"A Quantum Leap for the Web"（和訳）と題する記事でそう発表し、かなりの反響を呼んだ。日本でもIT関係のメディアで多数取り上げられており、目にされた方も多いだろう。

Quantumプロジェクトの進展に伴い、GeckoにはServoの成果が取り込まれていく。ServoはMozillaが2012年ころから開発してきたブラウザエンジンの試作品であり、Rust言語によって構築されている。必然的に、GeckoもRust言語ベースのコンポーネントが増えていく*2。これによりメモリ安全性（Memory Safety）、すなわちプログラムによるメモリ破壊が不可能な状態を段階的に作り上げる。従来は、Geckoにrust（錆）が増えていくことからOxidization（酸化）と呼ばれていた*3が、今後はたとえばQuantization（量子化）と呼ばれるのかもしれない。

Geckoが進化した先にある次世代のWebエンジン（Next Generation Web Engine：以下NGWE）では、マルチコアが当たり前になったCPUに並列的な処理を行わせるとともに、高速化が著しいGPUへの処理のオフロード化も積極的に進める。David Bryant氏は、2017年末までに改善の大きな成果を提供すると明言しているほか、初期の成果は同年前半のうちに出せるだろうとも述べており、Servoの取り込みは急ピッチで進められそうだ。

ServoのパフォーマンスをFirefoxと比較した動画を見れば、その処理の滑らかさは一目瞭然である。通常のWebページでも長大なものになると差は歴然としており、表示時間が数分の1になるとの報告もある。NGWEの開発が進めば、その高速化をFirefoxユーザーも享受することができる。

www.youtube.com

NGWEはWindows、Mac、Linuxに加えてAndroid向けにも提供されるが、iOSに関してはAppleがWebKit以外のブラウザエンジンを認めない限り、Mozillaが提供しようと思ってもできない。また、後述するQuantum CSSの開発計画からすると、Android版NGWEの提供はデスクトップ版よりも遅れそうだ。

サブプロジェクトの成果を順次導入

Quantumプロジェクトは、いくつものサブプロジェクトから構成されている。それらのうち、本記事執筆時点でQuantum - MozillaWikiに掲載されているものを紹介しておこう。ただし、Mozilla's Project Quantum and Servoで言及されているとおり、これらのサブプロジェクトは始まりにすぎない。Servoで試作が完成した機能は、これからも順次NGWEに移植されていくことになるからだ。

Quantum CSS

Quantum CSSはStyloとも呼ばれ、ServoのCSSスタイルシステムをGeckoに統合する（Bug 1243581）。work stealingアルゴリズムを採用してレイアウトの並列処理を行い、増分レイアウトという手法で演算を最小化する。スタイルシステムとは、HTML要素にどのCSSスタイルを適用するかを決めるもの。Servoには高速かつ並列処理が可能なスタイルシステムが実装されており、これを踏まえてStyloでは、Style Resolutionとセレクタマッチングの並列化を行う。増分リスタイルと呼ばれる手法の導入も予定されている（Bug 1288278）。

Quantum CSSの導入は、担当部分の処理に関し、Firefoxユーザーの95％に対し少なくとも2倍の速度向上をもたらす。さらにその約半数のユーザーにおいては、4倍以上の速度になるという。開発の進捗状況を踏まえると、比較的早い段階でFirefoxに投入されそうだ。

Quantum Render

Quantum Renderは、Servoの次世代レンダラであるWebRenderをFirefoxのグラフィックスバックエンドに据える（Bug 1311790）。WebRenderはCSSの処理に特化し、GPU向けに最適化されているため、Chromeが採用しているSkiaよりも効率的だとされる。

Quantum Renderは、OpenGL ES 2.1またはOpenGL 3をサポートした環境で動作し、低レベルな（決め細やかな操作ができる一方で書かなければならないコード量が増える）APIを提供する。また、Retainedモードを採用し、マルチスレッド化されている。これまでGeckoが採用してきたMoz2D APIとの関係は明らかではないが、仮にグラフィックスAPIを全面的に新しくするのであれば、開発には相当な期間を要することだろう。

Quantum Compositor

Quantum CompositorはGeckoのcompositorに独立したプロセスを割り当てるもの（Bug 1264543）で、Servoとは別に「GPUプロセス」の名で開発が進められてきた。compositorは、Webページ内のいろいろな要素が複数のレイヤーにレンダリングされているのを1つにまとめ、スクリーンに送り出す。Firefoxのマルチプロセス化（e10s）に伴い、compositorは既にchromeプロセス内の独立したスレッドとなっているが、このcompositorスレッドがプロセスとして独立するわけだ。

Quantum CompositorはWindows版Nightlyで有効化が目前に迫っており（Bug 1314133）、機能の完成度の点からみれば2017年前半のうちにリリース版で有効化されてもおかしくない。ただ、Windows 7 SP1以降でDXGI 1.2をサポートするアップデートを導入した環境が必須とされている点（Bug 1297822）は気にかかる。Windows 7でも古い環境だとQuantum Compositorが有効にならないと知ったユーザーが、FirefoxのためにOSをアップデートしてくれるかといえば、答えは否だろう。リリース版で有効化されるタイミング（Bug 1307578参照）は、有効化できるユーザーの割合を考慮しつつ決めることになるのではないか。

Quantum DOM

Quantum DOMは、それぞれのタブ（あるいはiframe）を、分離され協調的にスケジューリングされたスレッドに割り当てることで、Webコンテンツの動作をよりスムーズなものとし、プチフリーズの発生を抑える。Mozilla’s Quantum Project | Bill McCloskey's Blogで説明されているように、ユーザースレッド（ユーザー空間で実装されたスレッド機構）を自前のスケジューラで管理し、優先順位を付けて切り替えていく。

多数のタブを開いていても、タブごとにプロセスを割り当てていけばプチフリーズの発生は抑制可能だ。Chromeは現にそうしている。だが、プロセス数の増加は消費メモリの増大につながる。Mozillaの調査研究の結果によれば、現状でcontentプロセスを8以上に増やすことは、メモリ使用量との関係で許容できない。そこで、プロセス内をマルチスレッド化してプチフリーズに対処することにした。マルチプロセスに加えて各プロセス内をマルチスレッド化することは、技術的に決して容易ではないものの、Mozillaはあえてそこにチャレンジする。

Quantum Flow

Quantum Flowは、他のQuantumコンポーネントによってカバーされない領域におけるパフォーマンスの改善を探究するもので、UI最適化が例として挙げられている。

開発プロセスの進化と脱XUL化の加速

Quantumプロジェクトの語られざる意義について、筆者の考えを述べておきたい。手短に言えば、このプロジェクトはWebブラウザの開発のあり方に一石を投じる一方で、従来のGeckoとの互換性をかなり犠牲にすることになるだろう。

まずは前者について。これまで、Firefoxの開発プロセスは、Nightlyから始まり、Auroraで機能をほぼ固め、Betaでテストを繰り返し、リリースに至るという連結列車モデルを採用してきた。大規模な修正を伴う新機能を開発する場合は、Nightlyチャンネルのリポジトリ（mozilla-central）を分岐させたブランチを作成し、適当なタイミングでmozilla-centralに再統合していた。Quantumプロジェクトでは、これらのプロセスの外側に、Servoという実験的なブラウザエンジンを置く形となる。

Webがリッチで複雑なものとなった現在、そのプラットフォームとなるブラウザも複雑化が不可避だ。ブラウザエンジンについても同様であり、革新的な機能を投入することは次第に難しくなっていくだろう。そうした状況のもとでは、過去のしがらみを考慮せずに自由に実験ができる、相対的に小型のブラウザエンジンというカードを持っておくことが強みとなる。なぜなら、巨大化して技術的負債を多く抱えたエンジンをベースに新機能を開発するよりも、実験的なエンジンで得られた成果を移植するほうがコストが少なくて済むからだ。Mozillaの狙いはおそらくこの点にある。

Servoの側から見ると、今後も独立した製品にならないことが決定したと言えそうだ。2014年を振り返ると、Servoをモバイル向け製品に使う話が出ていたし、Firefox OSの基盤に用いることを検討した形跡すらある。だが、Firefox OS自体、スマートフォン向けの開発が打ち切られたうえ、Connected Devices（IoT）にレンダリングエンジンは必須ではないとの判断が下されたことで、進路を絶たれた。Servoの行く末も、Geckoのテストベッドに求めるほかなくなった。

次に、後者について。Mozillaは「跳躍」の先にあるものを懸命に見せようとしているものの、大きく跳べば元の場所から遠く離れるわけで、当然その場所を前提にしていた技術は失われる。具体的には、XULだ。Servoの実験的なフロントエンドがBrowser.htmlと呼ばれていることからも明らかなように、ServoはXULを使用しない。前述したようにNGWEはServoの取り込みを急速に進めるから、脱XUL化もかつてないスピードで進展していくだろう。

これまでも従来型の拡張機能がFirefox本体のバージョンアップに伴って動かなくなることはあったが、本体の修正に追随すれば再び動作するようになる例が大半だった。しかし、脱XUL化は次元の違う問題だ。WebExtensionsベースに移行しない限り、拡張機能は存続できない。完全テーマも同様で、WebExtensionsの一部となる新しいテーマAPIを利用することが要求される。

Quantumプロジェクトが互換性をどれだけ犠牲にするかは、Mozilla自身が一番よくわかっているはず。それでもなお過去と訣別し、未来に賭けるほかないとの決意が、このプロジェクト名には込められている。そこまでしないと生き残れないというところまで、Mozillaは追い詰められているのだ。

（16/11/05追記）
さっそく詳しい人から指摘があったので、本文を修正した。

StyloがやるのはLayoutじゃなくてStyle ResolutionとSelector Matcingの並列化。incremental layoutは、どのエンジンでもやってる。https://t.co/6Xk8QoECtN

— さねさね (@saneyuki_s) 2016年11月5日

*1:Firefoxをマルチプロセス化したElectrolysis（電気分解）プロジェクトが分子に関係していたことを踏まえた名称とみられるが、エンジン部分の名称をQuantumに変えるわけではない。

*2:rust-bindgenというバインディングジェネレータを使用する。

*3:Firefox 48に新メディアパーザが最初のRust言語製コンポーネントとして搭載された話は、記憶に新しい。

FirefoxのFlashサポートがいつまで続くか予想してみる

段階的に減らされるFlashのサポート

MozillaがFirefox 52でNPAPI（Netscape Plug-in API）プラグインのサポートを原則として打ち切る中、例外的にAdobe Flashプラグインだけはサポートが続く。プラグインが最新版であれば初期設定で「常に有効化する」扱いになるという優遇ぶりだ。この扱いはいつまで続くのだろうか。また、Flashプラグインのサポートが廃止されるのは、どの程度先のことなのだろうか。

Chrome 55以降でHTML5版コンテンツがデフォルトになるとか、Safari 10はHTML5版コンテンツを優先してプラグイン版コンテンツの有効化にはユーザーのクリックが必要といった話を耳にすると、Mozillaがすぐにでも追随しそうに感じるかもしれない。だが、かなり保守的な計画が立てられているのが実情だ。

Reducing Adobe Flash Usage in Firefox | Future Releases（和訳）で述べられているように、Mozillaは2017年中にFlashコンテンツをすべて「実行時に確認する」扱いにし、再生・実行時にはユーザーのクリックまたはタップを要求する（以下CtP：クリック・トゥ・プレイ）。他のブラウザが同年中にFlashのサポートを全廃する勢いなのに比べると、穏健な態度といえそうだ。ゆっくりと、しかし着実に有効化するFlashの数を減らしていく、というのがMozillaの方針なのである。

完全廃止は数年先

過去を振り返ってみると、MozillaがFlash以外のプラグインのサポートを廃止するまでに、ずいぶんと時間がかかった。2013年9月に原則CtP化の方針を打ち出したときは、急進的な印象を受けたものだが、2014年2月にはホワイトリストに掲載されたものは例外とされることになった。実際にリリース版でこの機能が有効化されたのは、同年6月のFirefox 30からだ。そして、ようやくFirefox 47になってこのホワイトリストが削除された。そこからさらにバージョンを5つ重ねて、上記のサポート廃止に至るわけだ。

しかも、ことFlashに関しては、ユーザーに与える影響の大きさからMozillaは慎重な姿勢を示すのが通例である。つい最近も、Firefox 49.0.2で非同期プラグインレンダリング（Asynchronous Plugin Rendering）の設定を有効化したところ、Flashコンテンツの表示が異様に遅くなる、Flashベースのゲームがプレイできないといった問題があちこちで発生したため、Mozillaはシステムアドオンを投入して、Windows向け32bit版では設定を再度無効化することにした。Flashのサポート廃止がMozillaの目標とはいっても、そこに到達するまでの道のりはたぶん長いものになるだろう。

2016年9月末にアナウンスされたMortarプロジェクトの存在も、Mozillaが近いうちにFlashのサポート廃止を打ち出すことはないだろうとの推測を裏付ける。このプロジェクトは、Googleが開発するPPAPI（Pepper Plug-in API）をFirefoxが内部的にサポートし、PDFiumライブラリとPPAPI版Flashプラグインを移植するというものだ*1。PPAPIはChromeのプロセス分離を前提に実装されているため、Firefoxのマルチプロセス機能（e10s）が完全に有効化されてからでなければ、Mortarプロジェクトの成果をNightlyチャンネルに投入することは難しいとみられる。

たとえば、Firefox Nightly 53にPPAPI版Flashが投入されるとして、バグを潰した後にAuroraチャンネルで有効化されるのは、早くてもFirefox 54だろう。そのままリリース版まで進むという最短コースを辿っても、ユーザーの手元に届くのは2017年6月だ。仮にMozillaが2世代先のESRのベースとなるFirefox 59（2018年3月リリース）でFlashのサポートを廃止するつもりなら、せっかく導入した技術がわずか9か月間しか利用されないことになってしまう。少なくともプラス1年はサポートを延ばすと考えるべきだろう。

想定されるプロセス

MozillaはFlashのサポート廃止に向け、大きく分けて2つの手段を採用する。1つはコンテンツの自動的な置き換えやブロックで、ユーザーが接触するFlashコンテンツを減らす試みだ。もう1つは既に述べた全面CtP化で、1つ目の手段でふるいにかけられたFlashコンテンツがユーザーのアクションなしに動作するのを防ぐ。

1つ目の手段は、一部が既に実装済みである。たとえば、Firefox 47では、Webサイト内に埋め込まれたYouTubeのFlash版動画プレイヤーを、HTML5版プレイヤーへと自動的に置き換えるようになった（Bug 769117）。この機能は、HTML5版コンテンツをプラグイン版コンテンツに優先させるという、より一般的な機能へと拡大される予定だ（Bug 1277346）。

また、Firefox 49では、トラッキングに用いられる不可視のプラグインが初期設定で無効化された（Bug 1268120）。この機能も、サードパーティーのドメインがFlashプラグインを起動させようとする場合、そのドメインがMozillaの管理するブロックリストに掲載されているときは起動を無効化するという、より一般的な機能へと拡大されていく（Bug 1277876）。Windows向け32bit版におけるwindowedモードの廃止（Bug 1296400）*2もこの流れに位置づけられるだろう。

2つ目の手段である全面CtP化は、今のところ手がかりがないので推測に頼るしかないのだが、まずは単純に既存の「実行時に確認する」を初期設定にするのではないか。この場合、ユーザーはアドオンマネージャで「常に有効化する」へと設定を変更することができるし、クリックしてFlashを有効化する際、特定のドメインでは「常に許可する」こともできる。

だが、おそらくMozillaが2017年中に目指しているのは、こうした常時有効化の設定を排除したCtP化だろう。つまり自動的に再生・実行されるFlashコンテンツはなくなり、ユーザーが積極的に有効化のアクションをとったコンテンツに限って、Flashが起動するわけだ。

さらにその先、2018年に入ると、「実行時に確認する」の設定を残しつつ「無効化する」が初期設定になっていくとみられる。タイミングとしてはFirefox 59のリリース時点で、ESRにおいては「実行時に確認する」が初期設定のままという形で分岐する可能性が高い。もっとも、Flash以外のプラグインがそうであったように、CtPから一足飛びに廃止という流れも考えられる。ただ、前述のMortarプロジェクトがESRだけを念頭に置いたものとは思われないので、やはり通常版でも有効化の余地は残すのではないか。

以上の推測が正しいとすると、FirefoxにおけるFlashのサポートが完全に廃止されるのは、通常版で2018年半ばから後半にかけて、ESRで2019年第1四半期以降になると予想される。

*1:ちなみに、JavaScriptアプリによるFlashプラグインの代替を目指したShumwayは、開発が事実上中止され、Firefox 47時点で本体からコードが削除された。

*2:64bit版では廃止済み（Bug 1248821参照）。

Firefox 52以降はFlash以外のプラグインが使用不可に こっそり使い続ける方法とは

MozillaはFirefox 52でプラグインのサポートを大幅に縮小する。具体的には、自動的にインストールされるもの（OpenH264 Video CodecやWidevine Content Decryption Module）を除くと、サポートされるのはAdobe Flashプラグインだけとなり、他のプラグインは使用できなくなる（Bug 1269807）。*1

アドオンマネージャの〔プラグイン〕の項目を見ると、あっさりした表示になっているのが分かる。Firefox 51までは有効・無効にかかわらず列挙されていたプラグインが、きれいさっぱり無くなっている。

Firefox 52以降もFlash以外のプラグインを使い続けたければ、延長サポート版（ESR）を利用してください、というのがMozillaのスタンスだ。この場合、Firefox 53以降に本体に追加される新機能は利用できなくなるため、ユーザーは（Flash以外の）プラグインを取るか新機能を取るかの二者択一を迫られることになる。

Flash以外のプラグインをこっそりと使い続ける方法を以下に紹介しよう。もっとも、今後のFirefoxはこれらのプラグインが動いていないことを前提に開発が進むため、Flash以外のプラグインがクラッシュの原因になっても修正されることはない点に注意してほしい。

上で述べたように、FirefoxのESRではFlash以外のプラグインもサポートが続いているわけだが、それを実現するのがplugin.load_flash_onlyの設定だ。about:configの画面で設定の欄を右クリックし、「新規作成」から真偽値の項目を選ぶ。そして、plugin.load_flash_onlyをfalseに設定する。

これで本体を再起動すればプラグインが無事復活……とはいかない。プラグイン用のキャッシュファイルが書き換えられており（Bug 1307501）、設定を変えても復活しないからだ。本体を再起動する前にこのキャッシュファイルを削除し、改めて作成するよう促す必要がある。

pluginreg.datという名のキャッシュファイルは、プロファイルフォルダ内に存在する。プロファイルフォルダへの移動は、Firefoxのヘルプメニューからトラブルシューティング情報（about:support）のページを呼び出し、〔アプリケーション基本情報〕のプロファイルフォルダ欄から「フォルダを開く」のが手っ取り早い。

まとめると、plugin.load_flash_onlyの設定をfalseの値にした状態で追加し、プロファイルフォルダ内のpluginreg.datというファイルを削除してから、Firefox本体を再起動する。これでFlash以外のプラグインは復活する。

（17/01/23追記）
同一プロファイルでESRと非ESRを切り替えた場合に混乱が生じないようにするため、plugin.load_flash_onlyの設定を追加して値をfalseにし、再起動するだけで、Flash以外のプラグインが復活するようになった（Bug 1330998）。もっとも、将来的に設定による切り替えはできなくしていく方針が示されており（Comment 17参照）、本記事の方法がいつまで通用するかはわからない。

なお、注に書いたAdobe Primetime CDMは、Firefox 52でアドオンマネージャに表示されなくなり（Bug 1329538）、Firefox 53でサポートが廃止される（Bug 1329543）。

*1:ちなみに、このバージョンから、Adobe提供のPrimetime Content Decryption Moduleはオンデマンドでのインストールとなる（Bug 1304899）。