Firefoxのコンテント・プロセス（Webページの表示部分）とクローム・プロセス（UI部分）を分離し、コンテント・プロセスをマルチプロセス化する流れは、既定路線と思われていた。しかし、Electrolysis（e10s）プロジェクトの先行きが不透明になったことで、雲行きが怪しくなっている。マイナビニュースの記事『Firefoxのマルチプロセス化、当面凍結 - 直近の性能向上を優先』で報じられているとおりだ。
小規模な案件に集中
Mozillaでe10sのプログラムマネージャを務めるLawrence Mandel氏は、『Update on Multi-process Firefox (Electrolysis) Development』という記事の中で、「Electrolysis initiative on hold for the foreseeable future」と表現している。e10sプロジェクトの活動を当面の間停止するという意味だ。Mandel氏によれば、e10sは対象が広汎にわたるため、開発の成果を得るには時間がかかりすぎる。そこで、活動をいったん停止して、より小規模な案件に集中して取り組むという。
案件の具体例として、プラグインの別プロセス化（OOPP）、Placesデータベースの最適化、JavaScriptにおける増分ガベージコレクションが挙げられている。いずれも、Firefoxの応答性を改善するために開発リソースを投入すべき分野とされているわけだが、その中にFirefoxのマルチプロセス化の第一歩ともいえるOOPPが含まれているのは興味深い。
また、Mandel氏は、e10sプロジェクトを停止する理由として、新しいマルチプロセス環境でアドオンが機能するかどうかを調査し、問題を解決する必要があるとも述べているが、これはあくまで既存のアドオンを指しているとみられる。
突然の動き
e10sプロジェクトの活動停止は、Firefoxの開発責任者クラスでも事前に連絡を受けていなかった。そのことを示すのが、mozilla.dev.planningの『E10s Planning, Plugins, and Responsiveness Meeting - Friday, Nov 4, 10AM PDT』というスレッドである。プロジェクトの定例ミーティングに参加できなかったHonza Bambas氏が結果を尋ねたところ、MozillaのVice President of Engineeringを務めるDamon Sicore氏から重大発表がもたらされた。
Sicore氏いわく、UIの無応答、ハング、スクロールやビデオ再生中のもたつきといった問題がユーザーから報告され続けており、長期的に大量のリソースが必要なe10sプロジェクトをいったん止め、CrashKillのような特別プロジェクトを起ち上げて、応答性の問題に対処するという。この発表に対し、Boris Zbarsky氏やRobert O'Callahan氏といった中心的な開発者たちが、e10sなしで問題をすべて解決できるのかと即座に疑問を呈しており、トップダウン的な意思決定が行われたことが窺われる。
ただ、スレッドが伸びている理由は、e10sとはあまり関係がない。Sicore氏が、「いつどこでSQLデータベースを使うかについて、つらい決断をしなければならない。SQLiteの代わりになるものを検討しなければならない」と述べたため、SQLiteを捨てるべきか否かで激しい議論が交わされたのだ。
Firefox Mobileはe10sから離脱
Android版FirefoxがネイティブUIを採用したニュースは、ご存じの方も多いだろう。Firefoxの起動時にGeckoとXULを用いず、Javaを使うわけだ。MozillaのLucas Rocha氏が『Native UI for Firefox on Android』で説明しているところによると、GeckoとXULは別スレッドに読み込まれ、ネイティブUIとメッセージのやりとりをする。このやりとりは、e10sではなく、より軽量なアーキテクチャのシステムを通じて行われるという。
新アーキテクチャの概要はMozillaWikiのFennec/NativeUI/Architecture Overviewで読むことができる。面白いことに、ネイティブUIの採用によってもXULが部分的に残る一方で、e10sはあっさりと捨てられてしまった。この動きは今のところAndroid版に限られるものの、今後進出するプラットフォームでも同じことが起きるだろう。e10sからの離脱はFirefox Mobile全体の方針と考えたほうがよさそうだ。
寝耳に水だったAdd-on SDKの開発チーム
2011年後半から2012年にかけて、Add-on SDK（旧Jetpack）の開発には最優先事項が3つあった。うち1つがアドオンの別プロセス化、つまりe10sの導入である。そこに降って湧いたようなe10sプロジェクトの活動停止。Piroさんが『e10sオワタ』で指摘されているように、開発チームにとってはしごを外された形だ。
しかし、MozillaのMyk Melez氏が『Why the Add-on SDK Doesn't "Land in mozilla-central"』で述べているように、Add-on SDKはリリース時期こそFirefoxの高速リリースサイクルとリンクしているものの、独立したプロダクトであり、開発をどう進めるかも自分たちで決めることができる。
Add-on SDKの開発チームが今後の方針を議論した内容は、『Future plans for "Out of the process add-on"'s』にまとめられている。結論をいえば、Add-on SDKベースのアドオンを別プロセス／スレッド／ワーカーで動作可能にするための開発は継続するそうだ。ただ、アドオンを独立したスレッドで動作させるプロトタイプについては、作業に着手するかどうかを検討するとしている。
デスクトップ版で復活の可能性あり
今回の動きを整理しよう。まずはmozilla.dev.planningでDamon Sicore氏がe10sプロジェクトの停止を表明し、これを受けてLawrence Mandel氏が記事を書き、Add-on SDKの開発チームが対策を協議した。他方、Android版Firefoxが新アーキテクチャを考慮せずにネイティブUIの採用に向けた開発を進めることは不可能だから、Firefox Mobileがe10sから離脱することを決めたのは、Sicore氏による表明よりもずっと前のことだ。時系列に沿うと、e10sの実装で先行するFirefox Mobileが離脱したため、デスクトップ版でもプロジェクトの再検討を迫られたという見方もできるだろう。
とはいえ、e10sを終わらせるには開発を進めすぎたのではないだろうか。これまでにかかったコストをすべて埋没費用で片付けられるのか。だいいち、コンテント・プロセスとクローム・プロセスの分離は、Webブラウザの主流だ。これが間違っているとすれば、Google ChromeもInternet Explorerも間違っていることになるし、Safariに至ってはわざわざWebKit2で間違った道を追いかけたことになってしまう。
Firefoxの応答性は、特別プロジェクトを通じて改善されてゆくのだろう。しかし、抜本的な対策としてのe10sの意義は失われていない。複数のタブを使うことがあたりまえで、Webアプリを「常駐」させることも珍しくなくなった現在、Webブラウザが丸ごとクラッシュする事態は非常にまずい。Mozillaが当面は対症療法を採用するとしても、根治の特効薬の入手を諦めるとは思えない。それに、Webコンテンツをサンドボックスに閉じ込める手法は、セキュリティ面で有効性が実証されている。いまさら別の手法を研究して実装するのは得策ではなく、この1点だけでもMozillaがe10sプロジェクトを継続する理由として充分といえよう。
さしあたっての課題を解決したら、デスクトップ版Firefoxではe10sプロジェクトが再開するだろうし、また、そうあるべきだと考える。
