Firefox 48から一部環境でマルチプロセス機能（e10s）が有効化 Firefox 53で完全実施へ（再追記あり）

アドオンをインストールした環境は対象外

Firefox 48リリース版では、ついにマルチプロセス機能（e10s）の有効化が開始される。ただし一部環境では、という留保つきだ。有効化された環境では、Webページを閲覧中にクラッシュやハングが発生しても本体が巻き添えにならないので、安定性が向上する。

対象にならない環境を挙げておくと、まずは近々サポート対象外となるOS X 10.6／10.7／10.8のほか、クラッシュ率上昇の問題を抱えるWindows XP（Bug 1275039）はまるまる除かれる。また、アドオンをインストールしている場合も対象外となり（Bug 1250744）、e10sが有効の状態でアドオンをインストールすると、Firefoxの再起動によりe10sが無効になる（Bug 1232274）。さらに、アクセシビリティツールが動作している場合（Bug 1198459、Bug 1260190、Bug 1277882）やRTL言語*1ロケールの場合（Bug 1234673、Bug 1243882）もe10sは有効にならない。*2

注意が必要なのは、Windows上でテキストやその他の項目を拡大する設定にしていることも、「アクセシビリティツールが動作している」とみなされる点だ。アドオンを入れていないのにe10sが有効にならないときは、ここで引っかかっている可能性がある。また、e10sが有効なときは以前紹介したAsync Pan/Zoom（APZ）機能も有効になる。Firefox本体がキビキビと動作する反面、Flashプラグインの利用時に問題が生じるかもしれない。

Firefox 48のリリース直後、e10sが有効化されるのは対象環境のリリース版ユーザーの1％に制限される（Bug 1284958）。これを数に直すと全Beta版ユーザーの数とほぼ等しくなることからこの割合が選ばれた。Beta版に関してはFirefox 44のころから継続的にe10sのテストが続けられており、Firefox 48 Betaではユーザーの半数について開発サイクルの全期間（6週間）にわたりe10sが有効化されている。つまり単純計算では、上記の1％はその2倍の数となるわけだ。Mozillaはここで様子を見て、問題がなければ対象ユーザーの範囲を広げていく。非対象環境を除くと、全リリース版ユーザーの約41％にe10sが提供される見込みだという。

7年をかけた一大プロジェクト

e10sの開発には紆余曲折があった。当ブログの記事を振り返ってみると、Firefox.nextでコンテンツとクロームのプロセスを分離 - Mozilla Fluxが初出のようだ。2009年5月に開発計画が公表されており、今から7年も前のことになる。単一であったFirefoxのプロセスを、ユーザーインターフェイス担当の親プロセス（chromeプロセス）とコンテンツ（タブ）担当の子プロセス（contentプロセス）に分けるこのプロジェクトは、水を水素と酸素に電気分解することになぞらえてElectrolysisと呼ばれるようになった。e10sは冒頭のEと末尾のsの間に10文字が挟まっていることを踏まえた略称だ。

Firefoxのマルチプロセス化はフェーズ2へ - Mozilla Fluxでは、安定性の向上、マルチコアプロセッサを活用したパフォーマンスアップおよびセキュリティの強化がe10sのメリットであること、ただしセキュリティの強化につながるサンドボックス化は将来の課題であることに言及していた。2009年6月の段階で、既にe10sの基本線は引かれていたことがうかがえる。その後、プラグインの別プロセス化を達成した時点でFirefox 4の完成を優先することになったものの、2011年3月にFirefox 4がリリースされ、同年7月時点で開発が本格化していた。

ところが、Electrolysis（e10s）は終わるのか？ - Mozilla Fluxで紹介したように、2011年11月になってe10sプロジェクトは突然活動が停止されてしまう。開発の成果を得るには時間がかかりすぎるので、まずはより小規模な案件に集中して取り組むというのがその理由だ。このとき、プロジェクトは停止と言いつつ実質的に中止されたのではないか、との意見も多かったように記憶している。

しかし、e10sプロジェクトは再開された。Mozilla may bring the multi-process architecture Electrolysis (e10s) back from the dead - gHacks Tech Newsという記事が出たのが2013年4月のこと。記事から間を置かずに開発者が再開を宣言した。同年12月には、Firefoxのコードレビューの際、e10s互換性のチェックが必須化され、再度のプロジェクト停止はほぼあり得ない状況となった。

開発再開からも既に3年の月日が流れた。それだけFirefoxに大改造を施すのがたいへんだったわけだが、ようやくゴールが見えてきた。

完全実施はFirefox 53の予定

最新のロードマップによれば、Firefox 50（2016年11月8日〔米国時間〕リリース予定）の時点で、アクセシビリティツールが動作している場合やRTL言語ロケールの場合、それにタッチスクリーン環境においてe10sが有効化される。他方、Windows XPのサポート時期は明らかにされていない。FirefoxとしてXPのサポートをどこまで続けるかという議論がなされている状況からすると、e10sは無効のままということもあり得る。

また、Firefox 51（2017年1月24日リリース予定）以降、順次アドオンがインストールされた環境でもe10sが有効化されていき、Firefox 53（2017年4月下旬リリース予定）で全面的に有効化される。Firefox 51の時点では、WebExtensionsベースの拡張機能に加え、ホワイトリストに掲載された従来型アドオン*3が対象となる。Firefox 52でリストの対象を広げ、Firefox 53でリストを廃止するという流れだ。早くもFirefox 49 Beta版ではホワイトリストのテストが始まり（Bug 1282120）、当初は9つのアドオンがリストに載る。

Mozilla Add-ons（AMO）に登録済みでユーザー数の多いアドオンに関しては、Are we e10s yet?でe10sへの対応状況を一覧できる。unknownの項目が多くて驚くかもしれないが、Firefox側に互換性を維持するためのライブラリ（e10s shims：Bug 1063156）が搭載されているので、現時点で動作するものも多い。

Firefox 53でe10sが初期設定において有効化されるようになったら、その先に待っているのはcontentプロセスの複数化だ。該当プロジェクトはe10s-multiと呼ばれ、その計画によれば、まずはcontentプロセスを2つにする。このとき、Service Workerには独立したプロセスが与えられるようになるらしい。当面の目標はcontentプロセスを5つに増やすことだが、単純にプロセスを増やすとメモリ消費量も増えてしまうため、メモリの利用状況の最適化を図り、様子を見ながらプロセスを増やしていくことになる。

強制有効化の設定

最後に、e10sを強制的に有効化する方法を紹介しておこう。既にLatest topics > Firefoxのマルチプロセス機能を強制的に有効化する方法まとめ - outsider reflexにまとめられているが、about:configの画面でbrowser.tabs.remote.force-enableをtrueに設定することで、「アクセシビリティツールが動作している」か否かのチェックを回避できる。また、extensions.e10sBlocksEnablingとextensions.e10sBlockedByAddonsを両方falseに設定することで、「アドオンがインストールされている」か否かのチェックを回避できる。原則として開発者向けだが、e10sの安定性やAPZのパフォーマンスを重視するユーザーにとっても選択肢となるだろう。

（16/07/31追記）
E10s/Status/July22 - MozillaWikiによれば、e10sが対象環境のリリース版ユーザーの5％に展開されるのが8月15日、100％に展開されるのが8月22日となる見込みだ。また、本記事執筆後、アクセシビリティツールが動作している場合のe10s有効化はFirefox 51へと延期された。

なお、本文を若干修正した。

（16/08/06追記）
前回追記後に出たWhat’s Next for Multi-process Firefox | Future Releases（和訳）が、e10sに関し3つの新情報を提供している。

1点目。e10sが有効化される環境に、WebExtensionsベースの拡張機能またはホワイトリスト掲載の従来型アドオンがインストールされていることを含める時期を、Firefox 50に前倒しする。その前提として、Firefox 49リリース版でも少数の従来型アドオンは実験的にe10s有効化の対象となる。仮にBeta版のとおりであれば、その従来型アドオンは、Greasemonkey、Download YouTube Videos as MP4、Video Download Helper、Lightbeam、Flashblock、Adblock Plus、uBlock Origin、Emoji Cheatsheet、Awesome Screenshot Plusの9つになるはずだ（Bug 1247497参照。ただし古いバージョンは除く）。他方、ホワイトリストの撤廃時期（＝e10sの完全実施時期）については上記記事中で触れられていない。

2点目。本文で触れたe10s-multiを2017年前半のうちに実現する。これがcontentプロセスを幾つにすることを指すのかまでは明らかにされていない。そして、e10s-multiと並行してプロセスのサンドボックス化も導入する。ここでは、Mozillaがサンドボックス化にChromiumのコードを利用していることが重要になってくる。GoogleがChrome 50でWindows XP／Vistaのサポートを打ち切ったため、Mozillaは現状のサポート環境を維持しようとすれば、Chrome 49相当のコードしか使うことができない（Bug 1287426）。Windows Vistaの延長サポートが2017年4月11日に終了することも考慮に入れると、サンドボックス化の話はFirefoxがESR以外でXP／Vistaのサポートを打ち切る布石かもしれない。

3点目。e10s-multiおよびプロセスのサンドボックス化が実現した後、拡張機能ごとにサンドボックス化されたプロセスを割り当てる。これはもともとAdd-on SDKベースの拡張機能に関して計画されていた内容である。しかし、今のMozillaはWebExtensionsを強く推す立場だ。元の計画を、コストをかけてXUL/XPCOMベースの拡張機能まで対象にするよう広げるとは思えない。つまり、独立プロセスでサンドボックス化されるのは、WebExtensionsベースの拡張機能に限定されるだろう。

以上のほか、E10s/Status/Aug05 - MozillaWikiによれば、2016年8月15日時点で、e10sは対象環境のリリース版ユーザーの10％に展開されることになった。前回追記時よりも前倒しされており、Firefox 48でのe10s展開は順調なようだ。

なお、再び本文を若干修正し、注を1つ加えた。

（17/04/30追記）
本記事の情報は、既に古くなってしまっている。最新の動向はマルチプロセス化の完全実施に先行してFirefox 54で多プロセス化を開始 - Mozilla Fluxを参照してほしい。

*1:RTLはRight-to-leftの略で、アラビア語やヘブライ語のように右から左に記述するのがRTL言語だ。

*2:このほか、タッチスクリーン環境も対象外のようだ。

*3:XUL/XPCOMベースのものとAdd-on SDKベースのものを含む。

FirebugはFirefox 49本体に統合 現行の2.0.x系列はマルチプロセス機能（e10s）に対応せず

Firebugは2006年から開発が続けられているWeb開発者向けツールで、「あなたはあらゆるWebページのCSS、HTML、及びJavaScriptをリアルタイムに編集、デバッグ、またはモニタすることが出来ます。」というのがうたい文句だ。Firefoxの拡張機能の中で最も有名なものの1つであり、現在でも200万人を超すユーザーがいる。開発チームのリーダーであるJan Odvarko氏はMozilla Corporationに在籍しているし、かつてはFirebugの動作に支障が出ることが、Firefox正式版のリリースを止めるバグ（Blockerバグ）にカウントされていたこともある。別格のアドオンといえるだろう。

そのFirebugが、Firefox 49で本体に統合される。公式ブログの記事"Unifying Firebug & Firefox DevTools"で説明されているとおり、FirebugはFirefoxの開発ツールに統合され、そのルック＆フィールは開発ツールのテーマとして維持されることになる（Bug 1244054）。Pixel Perfect*1やFireQuery、WebSocket MonitorといったFirebugの拡張機能も統合版Firebugと協調して動作する。

他方、現行のFirebug 2.0.x系列は、Firefoxのマルチプロセス機能（e10s）に対応しない。といっても、すぐに使えなくなるわけではない。たとえばFirefox 48の時点では、拡張機能が1つでもインストールされているとe10sが有効化されない仕様となっている。Mozillaもe10sが拡張機能に与える影響の大きさは十分承知しており、しばらくは上記の仕様が維持されるだろう。それとは別にe10sの有効・無効を切り替える設定もあるので、無効化してFirebug 2.0.x系列を使い続けることも可能だ。今のうちにFirefox Developer Editionで統合版Firebugを少しずつ試しておき、2.0.x系列からの乗り換え時期を探る手もある。

振り返ってみると、Firebug 3が2.0.x系列とは大きく違った形になることは、早くも2014年11月の時点でアナウンスされていた。"Firebug 3 – next generation of Firebug"はFirebug 3 alphaがリリースされたときの公式ブログの記事だが、そこではFirefoxの開発ツールが充実していく中、Firebugの重複する部分を整理し、Firefox本体との緊密な統合を実現することによって、ユーザー体験とともにパフォーマンスや安定性を向上させるという方針が示されていた。また、Firebug 3 beta 1がリリースされた2015年10月には、"Firebug & DevTools Integration ★ Mozilla Hacks – the Web developer blog"という記事が出て、Firebug 3はFirefox本体の開発ツール上に築かれた薄いレイヤーとなり、Firebugの独自機能も次第に開発ツールに移植されていくと説明されていた。

Firebug 2.0.x系列がe10sに対応しないことも、2014年12月の時点でアナウンスされている。"Firebug 3 & Multiprocess Firefox (e10s) ★ Mozilla Hacks – the Web developer blog"で述べられている内容は、要するに、e10sが有効化されるとFirebugはchromeプロセス側に置かれる一方で、操作の対象となるWebページはcontentプロセス側に置かれるので、処理の全面的な書き換えが必要になるということだ。本体の開発ツールと競合するのが目に見えているのに、膨大なコストをかけて書き換えを行う理由はない。そこで開発ツールと統合されたFirebug 3が作られることになった。

ただ、微妙な方針の変化もあったようだ。2015年12月にFirebug 3 beta 3がリリースされたのを最後に、拡張機能としてのFirebugは提供されなくなり、2016年2月には"Merging Firebug into the built-in Firefox Developer Tools"という公式ブログの記事で、Firebug 3のすべての機能をFirefoxにビルトインされたツールにする旨が発表された。当初は拡張機能としてのFirebugを残す方針だったが、どこかの時点で完全統合の方針に切り替わったのだろう。上記の記事によれば、Firefox本体の開発ツールに欠けた決定的な機能を提供する場合にのみ、Mozilla Add-ons（AMO）でFirebug 3を公開するという。

Firebug 3の統合はFirefox 49で完了するが、現行版のあらゆる機能が本体の開発ツールに実装されたわけではない。Bugzilla＠Mozillaには「Firebug Gaps」というバグが立てられており（Bug 991806）、今後もFirebug 2.0.x系列の機能の移植は続く。それでも、Firebugがその役割を終えたことは、Firefoxの開発ツールが1つのマイルストーンに達したことを意味する。WebExtensionsの普及という観点からも、Firebugが障害にならないのは大きいだろう。

*1:"Pixel Perfect 2: extension for Firefox Developer Tools ★ Mozilla Hacks – the Web developer blog"参照

Firefox 49本体のみで履歴等データベースのVACUUMが可能に

FirefoxはSQLiteというデータベース管理システムを用いて履歴とブックマークを管理しており、このデータベースのことをPlacesと呼ぶ。具体的にはplaces.sqliteというファイルだ。places.sqliteの肥大化と断片化はFirefoxのパフォーマンスを低下させるおそれがあるため、Firefox 3.6以降、データベースの断片化割合を推測しながら30日から60日に1回、アイドル時にVACUUM処理が行われる仕様となっている（Bug 512854）。places.sqlite内の項目が削除されて生じた空きレコードは、VACUUM処理によって解消され、それによって初めてファイルが圧縮されることになる。

ここまでは前提のおさらいだが、そうした知識があるかは別にして、要するにVACUUMすればFirefox本体の動作が軽くなると考えて、手動でこれを行うべく拡張機能を導入するユーザーが一定数存在する。実際には頻繁にVACUUM処理を実行してもあまり意味はないのだが、それはさておき拡張機能を入れるとなると互換性の問題が生じる。つまりFirefoxをバージョンアップすると動かなくなるケースが出てくるわけだ。

しかし、Firefox 49でトラブルシューティング情報（about:support）のページに「Places Database」（Placesデータベース）の欄が加わり、"Verify Integrity"（整合性の検証）というボタンが付いたことで、状況が変わるかもしれない（Bug 522668）。about:supportはロケーションバーに直接打ち込むか、メニューパネルのヘルプメニューから「トラブルシューティング情報」を選択すると呼び出せるが、そこにある整合性の検証ボタンをクリックすると処理が始まる。しばらく待つと結果が表示され、その中でVACUUM処理がされたことがわかる。処理前後のデータベースサイズを示してくれるので親切だ。

新規プロファイルで試してみた結果を以下に示しておこう。VACUUMの項目を見るとデータベースサイズは変わっていないが、削除された履歴やブックマークがない状態なのでこうなるのは当然である。

> Integrity check
+ The database is sane
> Coherence check
+ The database is coherent
> Orphans expiration
+ Database cleaned up
> Vacuum
Initial database size is 10240 KiB
+ The database has been vacuumed
Final database size is 10240 KiB
> Statistics
Database size is 10240 KiB
user_version is 32
page_size is 32768
cache_size is -2048
journal_mode is wal
synchronous is 1
History can store a maximum of 104858 unique pages
Table moz_places has 11 records
Table moz_historyvisits has 4 records
Table moz_inputhistory has 0 records
Table moz_hosts has 4 records
Table moz_bookmarks has 15 records
Table moz_keywords has 0 records
Table sqlite_sequence has 0 records
Table moz_favicons has 8 records
Table moz_anno_attributes has 3 records
Table moz_annos has 1 records
Table moz_items_annos has 4 records
Table sqlite_stat1 has 14 records
Index sqlite_autoindex_moz_inputhistory_1
Index sqlite_autoindex_moz_hosts_1
Index sqlite_autoindex_moz_keywords_1
Index sqlite_autoindex_moz_favicons_1
Index sqlite_autoindex_moz_anno_attributes_1
Index moz_places_faviconindex
Index moz_places_hostindex
Index moz_places_visitcount
Index moz_places_frecencyindex
Index moz_places_lastvisitdateindex
Index moz_historyvisits_placedateindex
Index moz_historyvisits_fromindex
Index moz_historyvisits_dateindex
Index moz_bookmarks_itemindex
Index moz_bookmarks_parentindex
Index moz_bookmarks_itemlastmodifiedindex
Index moz_places_url_uniqueindex
Index moz_places_guid_uniqueindex
Index moz_bookmarks_guid_uniqueindex
Index moz_keywords_placepostdata_uniqueindex
Index moz_annos_placeattributeindex
Index moz_items_annos_itemattributeindex

もはやPlacesをVACUUMするためにわざわざ拡張機能を入れる理由はなくなった。拡張機能を入れなければ、互換性問題に悩まされることもない。ただし、より高度なメンテナンスを行う場合は、Places Maintenanceのような拡張機能にもまだ出番がある。

Firefox 50でページ内検索結果の表示方法が変更（再追記あり）

Firefox page search improvements - gHacks Tech Newsで既報のとおり、Firefox 50ではページ内検索結果の表示方法に変更が加えられた（Bug 384458）。ヒットした結果が目立つように、背景が薄暗く表示される一方、対象項目はかなり明瞭な形で強調表示されるようになっている。加えて、ヒット数の上限も100件から1000件へと引き上げられた。

ヒットした項目は、黄色っぽい背景のボックスごと飛び出たような感じになり、特に最初の項目は文字のサイズも大きくなっている。画面内に他にヒットした項目がある場合、それらは薄暗い背景にそこだけ光が当たったかのように明るく表示される。次の項目に移るときは、上記の黄色っぽいボックスが、ビヨーンとジャンプするようなエフェクトがかかる。全体的にかなり派手な印象だ。

面白い機能だが、デザインに関しては好みが分かれそうである。元の表示に戻したいときは、about:configの画面でfindbar.modalHighlightとfindbar.highlightAllの設定を両方ともfalseに変更すればよい。

（16/09/18追記）
この機能はFirefox 50では無効化されている。開発中に多数のバグが見つかったためだが、現在ではそれらも概ね修正されており、Firefox 51リリース版では初期設定で有効化される見通しだ（Bug 1291284）。なお、Firefox 50では完全一致検索のオプションが設けられている（Bug 269442）ため、ページ内検索機能の改良点がなくなったわけではない。

（16/09/29追記）
上記の追記後、Firefox Nightly 52以外では再び初期設定で無効とされた（Bug 1303248）。初期設定で有効化される時期は、Firefox 52リリース版に延期されたものとみられる。

（17/01/23追記）
本機能が初期設定で有効化される時期は、Firefox 52リリース版である（上記Bug 1291284参照）。

（17/04/30追記）
結局、Firefox 52/53リリース版では有効化されなかった。しかもFirefox Nightly 55でこの機能が無効化されており（Bug 1355596）、当面は現行バージョンが維持されることになりそうである。

Firefox 49で追加された「最近のブックマーク」の表示を消す

Firefox Developer Editionがバージョン49.0a2へとアップデートされた。アップデート後にブックマークメニューを開くと、目立つ位置に"Recently Bookmarked"という欄ができ、5項目のブックマークが並んでいるのに気付くだろう。この「最近のブックマーク」は、ユーザーがWebコンテンツをブックマークすると更新されていく。新規のブックマークへのアクセスを容易にすれば使い勝手がよいだろうという配慮だ。

Firefox Nightly 47で導入された（Bug 1219804）新機能だが、Auroraチャンネル（Developer Edition）に移行する際に外され（Bug 1254960）、Firefox 48でも同様の措置がとられた（Bug 1267939）。Firefox 49でDeveloper Editionに投入されたところを見ると、このままリリース版でも有効化されるだろう。

しかし、この新機能を鬱陶しいと感じる人もいるはずだ。星アイコンをクリックしてWebコンテンツをブックマークすると、通常は〔未整理のブックマーク〕（Firefox 48以降は〔他のブックマーク〕）というフォルダに格納されるのだが、その項目がそのままメニューに出てきてしまう。Mozillaとしてはまさにそこが狙いで、どこにブックマークしたのか忘れてしまってもブックマークにアクセスできるようにしたわけだが、大きなお世話という感じもする。自分で格納したフォルダと違うところに項目が表示されるのは嫌だという意見もあるだろう。

また、始末の悪いことに、ブックマークメニューの幅は一番長い項目・フォルダ名によって決まるので、長い名前のブックマークをフォルダに格納してメニューの幅を抑えるようにしていても、項目名がそのまま出る「最近のブックマーク」のせいで台無しになってしまう。個人的にはここが一番許せない点だった。

幸い、「最近のブックマーク」は設定でオフにできる（Bug 1248268）。手っ取り早いのは、ブックマークメニュー上で右クリックしてコンテキストメニューを開き、"Hide Recently Bookmarked"（最近のブックマークを隠す）をクリックすることだ。なお、about:configの設定画面を開き、browser.bookmarks.showRecentlyBookmarkedをfalseに変更しても同じ効果が得られる。