Firefox ESR 24から31へ

Firefoxの法人向け延長サポート版であるFirefox ESR 31が2014年7月22日（米国時間。以下同じ）にリリースされ、ESR 24のサポート終了が10月14日に迫っている。もともといくつかリリースを重ねた段階で打ち切られる予定だったFirefox ESRだが、最近、今後も継続していくことが発表された。Chromeが企業向けサポートを提供する中、少なくとも200万のユーザーがいるというチャンネルを維持するのは賢明だろう。

では、Firefox ESR 24のサポートが切れた時点でESR 31に移行するとして、両者の目立った違いは何だろうか。Mike's Musings「The Next Firefox ESR (31) is Almost Here」によれば、まずはAustralisだ。ユーザーインターフェイスが大幅に刷新されたわけだが、馴染めないのであれば、Classic Theme Restorer (Customize Australis) というアドオンを利用すれば、かなりの程度までAustralis以前の姿に戻すことができる。

また、Firefox SyncがFirefoxアカウントベースの新しいものに置き換えられたほか、Configurable Security Policies（CSP）も削除されている。ただし、CSPの削除は企業ユーザーへの影響が大きいため、Webページからローカルファイルにリンクする機能は残された。

以上に加え、プラグインがデフォルトでクリック・トゥ・プレイ化（CtP）されたことも大きい。CtPとは、Webページが読み込まれた時点ではプラグインが自動的に有効にならず、ユーザーがプラグインのコントロールする領域をクリック（スマートフォンやタブレットではタッチ）した時点で初めてプラグインが有効になる仕組みのことだ。例外的に、Adobe Flash Playerプラグインや、アドオンにバンドルされたプラグイン（Bug 982101）は常に有効になるよう設定されている。

CtPを解除するには

CtPのデフォルト化に伴い、企業ユーザーが自社で開発したプラグインをFirefoxにインストールしている場合も、自動的に有効にならなくなってしまう。いちおうFirefox本体にはCtPの例外を認めるホワイトリストの仕組みが備わっているものの、これはプラグインを開発して一般向けに公開している企業を念頭に置いて、Web標準を用いた代替策を講じるまでの猶予期間を提供する目的で設けられたものだ。ホワイトリストに掲載されるには、申込み時にNPAPIベースのプラグインからの移行プランを示す必要があるうえ、掲載期間は30週間で、24週間の延長が1回だけ可能という厳しい制限付き。それでいて掲載の可否はMozillaの自由裁量に委ねられ、掲載期間中に外されることさえあり得る。実際のリストを見ても大手企業が多く、内製のプラグインを対象にしたものでないことは明らかだ。

幸い、Mike's Musings「Plugins Click-To-Play by Default in Firefox 31 ESR」では、内製のプラグインにも適用可能な4つの方法が紹介されている。

1つ目は、about:configにおいてplugin.default.stateの設定値を2に変更する方法だ。こうすることで、CtPはデフォルトでなくなる。言い換えれば、従来どおり全プラグインが読み込み時に自動的に有効になる。

2つ目は、plugin.state.FILENAMEの設定値を追加する方法だ。FILENAMEにはプラグインのファイル名を小文字で記載し、末尾の数字などは付けない。たとえばWindows版でplugin.state.nppdfの設定項目を追加し、値を2に設定すると、Adobe AcrobatプラグインだけがCtPから外れる。

3つ目は、CCK2 Wizardというアドオンを利用して、設定をカスタマイズしたFirefoxを作成し、特定のドメインを対象にプラグインを有効化する方法だ。ちなみに、このアドオンの作者は、上記Mike's Musingsのブログ主である。

4つ目は、Click-to-Play Managerというアドオンを利用し、特定のドメインを対象にプラグインを有効化する方法だ。

手っ取り早く対処するなら1つ目の方法だが、セキュリティを犠牲にしないためには他の選択肢も考慮に値するだろう。いずれにせよ、対処法は確立されており、CtPはFirefox ESR 31に移行する際の障害にはならないといえる。

構想から2年半以上をかけてリリース版へ

Firefox 32では、新しいHTTPキャッシュ（以下cache v2）が標準で有効化された。リリースノートでは、世代別GCの統合よりも上の、トップの項目に挙げられており、Mozillaがこの機能を重視していることがわかる。実際にも、特にAndroid版Firefoxを使っているとコンテンツの表示がスムーズになっているのを体感できる。

cache v2がブラウジングに与える影響は大きい。過去に閲覧したWebページを再度閲覧する場合、キャッシュの性能次第で表示の完了までにかかる時間が変わってくるのはもちろんだが、通常、Webページを閲覧した時点でディスク上にキャッシュが生成されるようになっているため、この処理が遅いとFirefox本体の動作の足を引っ張ることになる。

その影響の大きさゆえに、cache v2の設計と実装は慎重に進められた。最初に構想が明らかにされたのは、2012年1月25日（米国時間。以下同じ）、mozilla.dev.tech.networkの"Upcoming Cache Work"というスレッドにおいてである。そこでは、以下のようなコンセプトが示された。

• ロックの競合を減らす。キャッシュ全体が1つの大きなロックによって保護されているのを、より粒度の細かなものとする。
• メインスレッドとキャッシュスレッドの間でやりとりする時間を減らす。
• キャッシュ内の並列性を高める。スレッドを2つ以上にしてI/O処理のボトルネックを解消する。
• ディスクキャッシュのフォーマットを変更し、キャッシュの大規模な削除を少なくする。
• クラッシュ後の再起動時にキャッシュ全体を削除しなくても済むようにする。
• エントリをより効率的に保存する。エントリとメタデータを1つのファイルに統合する。

その後、MozillaWikiのNecko/Cache/Plansがいろいろと修正され、履歴によれば、cache v2の設計がほぼ固まったのは、2013年3月ころとみられる。デザインの目標から主なものを挙げてみよう。

1. キャッシュのためのAPIをバージョン化し、アップデートを容易にする。
2. すべてのAPIを非同期化し、メインスレッドのロックを防ぐ。
3. 異常終了してもキャッシュ全体を破棄しない。
4. gzip圧縮をサポート。
5. ディスクキャッシュが完全に無効化されてもブラウザが正常に動作する。
6. 通信待ちを減らす。

Firefox 27 Nightlyにcache v2が実装されたのは、2013年9月20日のことだ（Bug 913807）。この時点では、まだデフォルトでは無効化されていた。開発者のHonza Bambas氏は、mayhemer's blogの記事"Mozilla Firefox new HTTP cache is live!"の中で、クラッシュや（プロセスの）キル後もキャッシュエントリが維持され、UIのハングも起きないという点を強調していた。また、2013年第4四半期中にはデフォルトで有効化されるとも述べており、そのとおりであれば、2014年第1四半期か、遅くとも第2四半期の初めには、リリース版にcache v2が投入されていたはずだ。

ところが、cache v2に切り替えてもクラッシュが起きないようにするなど、仕上げに時間がかかったため、2013年12月10日時点で、デフォルト有効化の時期はFirefox 31へと延期された。しかも、この予定も若干ずれ込み、リリース版でも有効化されることになったのは、Firefox 32の開発サイクルに入った後の2014年5月16日であった（Bug 913806）。

Firefox 32が2014年9月2日にリリースされ、cache v2は、構想から実に2年半以上を経て一般ユーザーの手元に届くことになった。設計が固まってからでさえ、1年半近い期間が経過しており、大きなプロジェクトであったことがわかる。

cache v2の特長

実装されたcache v2がどのようなものか、mayhemer's blogの記事などを参照しつつ、より詳しく見ていこう。

旧APIは廃止

以上のようにcache v2はcache v1とは別物であり、これに伴ってAPI（HTTP Cache | MDN参照）も全面的に刷新されたため、Firefox 32では、互換性のないcache v1のAPI群は廃止された。

APIが廃止になるとキャッシュからファイルを拾うタイプのアドオンなどに影響が出そうだが、mayhemer's blog"Firefox HTTP cache v1 API disabled"のコメント欄を見ると、2014年6月の時点で、Mozilla Add-ons（AMO）に登録されているアドオンについてはソースコードの調査が行われたらしく、現在もメンテナンスがされているアドオンの中で、マイグレーションが必要なものは見当たらなかったという。

Flashプラグインのクラッシュが頻発

Nightlyで新しいWebページを開いた際、Flashコンテンツが含まれていると、しばらくブラウザごとハングした後でプラグインがクラッシュする。たまにクラッシュしないこともあるが、たいていの場合は使用に堪えない。

原因は、Windows版Nightlyのビルド環境がVisual Studio 2013（VS2013）に移行したこと（Bug 1061335）にある。従来のVS2010と比較してビルド時間が短縮され、リンク時に仮想メモリを消費し尽くす問題も解決される（参照）など、移行のメリットは大きいのだが、Flashプラグインが保護モードでうまく動作しないという思わぬ副作用があった。

開発元のAdobeも問題を把握しており（Bug 1082670）、Flashプラグインの修正によって解決されればよかったのだが、残念ながら近いうちにアップデートが提供される可能性は低い。Adobeの開発者とみられる人物が、「VS2010に戻すという選択肢もあるので喫緊の課題とはいえない。Flash PlayerをVS2013環境にアップデートして解決することは短期的にはあり得ない。」という趣旨のコメントをしているからだ。

Flashプラグインを無効化すればクラッシュなどは起きなくなるが、それでは解決にならない。広告はともかく、動画コンテンツはFlashを必須とするものがまだまだ多い。YouTubeのようにHTML5プレイヤーを別途提供しているところは少なく、動画でニュースを見ることができないのは相当に不便だ。

そこで、Flashの保護モードを解除することにした。具体的な手順は、もずはっく日記「Firefox上で、Flash Playerが遅い、ハングアップする、日本語入力できない、という方には、保護モードの解除をお勧めします」が詳しいので、そちらを参照してほしい。

なお、Windowsのユーザー環境変数に変数名「MOZ_DISABLE_OOP_PLUGINS」および値「1」を設定したうえでブラウザを（再）起動することで、プラグインの別プロセス化を解除する手もあるが、Flash以外のプラグインにも影響するのであまりおすすめできない。

保護モードを解除すると安全性は低下してしまうが、利便性とのバランスを考慮した結果である。今のところはMozillaが開発中のShumwayも選択肢には入らない。年内にはNightlyで有効化されそうではあるものの、当初はホワイトリスト方式で様子を見るとされており、Flashを完全に代替するにはほど遠いからだ。

とはいえ、Mozillaもリリース版までには何らかの手を打つ必要がありそうだ。影響の大きさからすると、Adobe側の対応が遅れた場合、ビルド環境をVS2010に戻すことも検討に値しよう。

（14/10/26追記）
上記のBug 1082670は修正された。幸い、Mozilla側で比較的容易に対処できる問題だったようで、クラッシュレポータのコードがVS2013との組み合わせでうまく動作していなかった点が直された結果、ハングやクラッシュは起きなくなった。

これを受けて筆者の環境も、Flashプラグインの保護モードを再度有効化した。実のところ保護モード解除中は、複数のタブ内でFlashが動作している場合に、1つのタブを閉じると他のタブでFlashがクラッシュすることが増えていたので困っていた。しかも、保護モードは全プロファイルに共通のため、今まで問題が出ていなかったAuroraなども使い勝手が悪くなっていた。その意味で、Nightlyで修正してくれたのはありがたい。

どうもAdobeは保護モード解除時の動作の安定性を十分に考慮していない節がある。保護モードの解除は、あくまで緊急避難的な措置として位置づけるのがよさそうだ。

はてなブックマーク拡張が機能しない

Firefox Nightly 36では、はてなブックマーク拡張が全く使えない状態になっている。Webページを表示してもブックマーク数が取得されないし、ブックマークに追加しようとボタンを押しても反応がない。しかも、カスタマイズモードに入ると「追加のツールと機能」に一切アイコンが表示されない。Build 20141018030201と新規プロファイルを組み合わせて、プラグインもすべて無効化してみたが、以下のスクリーンショットのように状況は変わらない。なお、上記のはてなブックマーク拡張は、以前に紹介した非公式修正版である。

実はこの現象、Nightly 35の途中で発生していたのだが、不思議なことにAurora 35では発生しない。Aurora 34を35にアップデートした後も、はてなブックマーク拡張は普通に使えている。Nightlyだけで有効化されている何らかの機能が影響しているのだろうか。とにかく、解決法が見つからないので、はてなブックマーク拡張は無効化した。

はてなが拡張機能の開発に取り組んでいるのであれば、GitHubのIssuesに登録するところだが、devブランチを見ても2013年9月25日が最終更新日となっており、1年以上も動きがないありさまだ。Firefox 29以降にちゃんと対応するには修正が必要だとわかっているはずなのに、どうして開発を再開しないのか。

担当者がいないとか、担当者はいるが他の仕事が忙しくて手が回らないとか、いろいろ理由は考えられるが、いずれにしろマネージメントがしっかりしていれば解決できる問題だろう。アプリやスマートフォン版だけでなく、拡張機能のユーザーにも目を向けてほしいものだ。

（14/12/16追記）
Firefoxアドオンをアップデートしました - はてなブックマーク開発ブログで告知されているとおり、公式版のはてなブックマーク拡張がバージョン2.3.6.1へとアップデートされた。筆者の手元のNightly 37で動作することを確認した。

祝10周年

2014年11月9日にFirefoxはバージョン1.0のリリースから10周年を迎えた。これを受けて10日以降、「忘れる忘却」ボタンの追加などユーザーのプライバシーに配慮したFirefox 33.1がリリースされ、Firefox AuroraがWeb開発者向けにリニューアルされて「Firefox for DevelopersFirefox Developer Edition」の名称で提供されるなど、さまざまなMozillaの企画が実行されていく。

10周年記念キャンペーンの一環として、Windowsユーザー向けに64bit版Firefoxのプレビューが提供されるとみられる。本記事では64bit版Firefoxの正式提供に向けた動きをまとめてみたい。

（14/11/10追記）
確定したブランド名を見落としていたので修正（Bug 1072181）。ボタン名もリリース版の表記に合わせた。

正式提供が決まるまで

振り返ってみると、Mozillaは比較的早くから64bit版Firefoxの正式提供を視野に入れていた。2010年4月ころにプロジェクトが始まり、同年5月末には、ビルドが自動化されたWindows向け64bit版Firefoxが、テスト目的で公開されている（"Pre-release Firefox Windows 64-bit builds now available (testing purposes)"）。どれくらい前かというと、Firefox 3.6のリリースがその年の1月だ。次のFirefox 4はまだBeta版にも至っておらず、バージョンも3.7になるとされていた。上記のテスト版も、動作させるには別途Microsoft Visual C++ 2010 Redistributable Package (x64) のインストールが必要であり、対象ユーザーが限定されていることは明らかだった。

2011年3月にFirefox 4がリリースされるまでは、プロジェクトは少しずつしか進まなかったが、Mozilla Corp.のAsa Dotzler氏（同年6月にDirector, Firefox Productに就任）が、64bit版Firefoxの提供に積極的だったこともあり、同年7月には32bit版と同様にビルドシステムが組まれ、ユーザーがNightlyビルドを継続的に使用してテストできるところまでこぎ着けた（"Firefox and Windows 64-bit builds (testing version; not a release version)"）。

2011年10月には、Firefoxの主要開発者たちの間で、Windows向け64bit版Firefoxを提供するメリットとデメリットが議論されている（"Firefox 64-bit for Windows: data gathering"）。そこでは、仮想メモリ不足でクラッシュすることが減り、全体としてパフォーマンスが改善し、セキュリティも強化されることがメリットとして、メモリ消費量が増加し、JavaScript JITの性能が低下し、プラグインやバイナリベースの拡張機能が動作しないことなどがデメリットとして、それぞれ挙げられていた。Firefox 7のころのことである。

64bit版に向けた積極的な動きは、Linux向けFirefoxに関しても見られた。Firefox 15がリリースされた直後の2012年8月末、ビルドやテストのキャパシティを確保するため、32bit版または64bit版のいずれかに絞るべきではないかとの議論が開発者たちの間でなされ、その際、32bit版をフェードアウトさせる方向で検討すべきとの意見が多数を占めた（"Future of Linux64 support"）。

ところが、Firefox 17がリリースされる直前の2012年11月17日（米国時間。以下同じ）、突如としてWindows向け64bit版Firefox Nightlyの提供を停止するとアナウンスされた（"Turning off win64 builds"）。2013年中に正式版リリースの予定がなく、また、プラグインのサポートも進まない中、Firefox for MetroやFirefox OSの開発に集中する必要があるというのがその理由である。

もっとも、このアナウンスに対するユーザーの反発は大きく、Mozillaは軌道修正を余儀なくされる。大量のタブを開くため32bit版ではメモリが足りないというユーザーにも配慮して、現行の64bit版ユーザーにはいったん自動アップデートを通じて32bit版を提供するが、その後も64bit版のビルドやアップデートは提供を続けるとした（"Update on turning off 64-bit Windows builds"）。つまり、強制移行後に64bit版を改めてインストールすれば、使い続けることができるというわけだ。ただし、64bit版の自動テストは無効化され、ビルドもmozilla-centralリポジトリからNightlyを作成するときに限られる（Bug 814009）ことになったため、安定して動作しない可能性は高まった。

Mozillaが開発の優先度を下げた結果、その後1年以上にわたって64bit版の話題は途切れる。ちなみに、Firefox 28がリリースされる直前の2014年3月中旬には、Firefox for Metroの開発が先に中止されてしまった。

しかし、ユーザーからは見えないところで、2014年4月以降、事態が動き始めていた。Mozilla Corp.のJavaun Moradi氏（同年3月にProduct Manager, Firefoxに就任）がWindows向け64bit版Firefoxのローンチに向けた評価を開始し、Firefox 30のリリースが近づく同年6月4日、その旨を明らかにしたのだ。

そして、2014年9月中旬ころ、Mozilla Corp.のJohnathan Nightingale氏（Vice President, Firefox）やGavin Sharp氏（Firefox Dev Lead）などの最高幹部を交えた会議で、Windows向け64bit版Firefoxを正式に提供することが決定された。このとき、Firefoxのバージョンは32に達していた。

Mozillaが64bit版Firefoxを提供する理由

Mozillaが再び64bit版Firefoxの提供に積極的になった背景には、競合他社の動きや、マーケットの変化があった。当初はわずか1％のアーリーアダプターが使用するだけのものになるにせよ、提供すること自体に意義を見出したのである。

Firefox/win64 - MozillaWiki*1に記載されているとおり、競合他社の動きとは、Internet ExplorerとChromeが既に64bit版を提供していることを指す。特にGoogleはChrome 37でオプトイン方式とはいえWindows向けに安定版を提供し、Chrome 39ではMacユーザーを自動アップデートを通じて64bit版に移行させる。しかも64bit化はスピード、安定性、セキュリティのすべてにメリットがあるとアナウンスしており、Mozillaとしても無視はできない。

マーケットの変化とは、ゲーム開発者がブラウザベースのゲームに本格的に取り組み始めていることを指す。MozillaはゲームがWebのキラーコンテンツとなり得ることを十分に理解しており、オープンなWeb技術を用いた高品質のゲームが豊富に提供されるようになれば、特定のOSに囲い込まれるのを防ぐことができると考えている。そのためには、ブラウザ自体が信頼できるプラットフォームとなる必要があり、64bit版のパフォーマンスや安定性が信頼性の向上に役立つというわけだ。64bit版Firefoxを正式に提供することで、Mozillaはゲームを重視していると開発者に対して行動で示すことができる。

また、64bit版Firefoxの提供は、MozillaにとってNPAPIプラグインとバイナリベースの拡張機能のサポート状況を大きく変えるチャンスとなる。これらはFirefoxの安定性を損ない、マルウェアの温床ともなってきたものだ。

64bit版Firefoxの提供プラン

Windows向け64bit版Firefoxは、ユーザーに対し段階的に提供される。10周年記念のリリースはその第一歩であり、スタンドアローン型のインストーラでNightly（36）のみならずAurora（35）やBeta（34）のコードをベースにしたビルドも提供される一方、自動アップデートには対応しないようだ。

本格的な提供は、Firefox 37（Nightlyチャンネル入りが2014年11月25日、リリースが2015年3月31日を予定）からとなる。このフェーズ1では、自動テストを経たビルドが作成され、スタンドアローン型のインストーラが"what's new"ページで提供され、自動アップデートにも対応するが、Flashプラグインやバイナリベースの拡張機能のサポートは保証されない。

時期は未定だが、フェーズ2になるとスタブインストーラに64bit版が統合され、ユーザーはインストール時にこれを選択できるようになる。FlashはShumwayまたはAdobeがサポートする64bit版プラグインによってカバーし、拡張機能のサポートも拡大する。バイナリベースの拡張機能にはjs-ctypesによるものとXPCOMによるものの2種類が存在しており、Firefoxのマルチプロセス化（e10s）に伴ってXPCOMによるものは廃止される見込みだが、js-ctypesによるものは少なくとも限定的なサポートを維持するということだろう。

フェーズ3に至ると、64bit版Firefoxは自動アップデートによって32bit版ユーザーに提供される。ユーザーが明示的に32bit版の提供を求めない限り、64bit版へと移行することになる。とはいえ、32bit版Windowsを利用するユーザーに64bit版Firefoxを提供するわけにはいかないので、そこはインストーラが判別するはずだ。

気になるのはその先、32bit版の提供終了についてだが、今のところ情報はない。現時点でFirefoxユーザーにおける64bit版Windowsの利用率は50％とのことなので、MicrosoftがWindows XPのサポートを終えた後もMozillaがXP SP2以降をシステム要件に残していることを考慮すると、かなり長期にわたって32bit版の提供は続けるのではないか。ただ、GoogleがMac OSでは64bit版Chromeを強く推しているので、こちらはプラグインのサポートなどに目途がつけば、64bit版への一本化が先行するかもしれない。

（14/12/07追記）
現在の状況についてだが、自動アップデートに対応しない10周年記念リリース（いわばフェーズ0）は発表されず、代わりに上記のフェーズ1が前倒しされた。米国時間で11月10日からFirefox Nightly BuildsのWebサイトで64bit版のフルインストーラがダウンロード可能になっている。

64-bit Firefox is now available as nightly prerelease builds: https://t.co/sSPpQ1CeVc#fx10

— Benjamin Smedberg (@nsIAnswers) 2014, 11月 10

ただし、サポート対象がWindows 7以降である点に注意が必要だ。Vista以前だとインストールも起動もできなくなっている（Bug 1093741、Bug 1094013）。

Mozillaの新戦略

Firefox10周年のお祝いムードが一段落したところで、今回のキャンペーンについて振り返ってみたい。Mozillaは、Firefoxと特定の価値とを強く結びつけるという大きな一歩を踏み出したように思われるが、本当にそれでよかったのだろうか。

たとえば、Chris Beard氏（Mozilla Corporation CEO）の記事"Celebrating Choice, Control and Independence On the Web"を見てみよう。そこでは、FirefoxがMicrosoftの支配するWebを変え、今日では何億人もの人々に自立と機会を提供しているとして、支持を求めるメッセージが打ち出されている。また、同記事内に掲載されている大型バナーには、"CHOOSE INDEPENDENT. CHOOSE FIREFOX." （自立を選ぼう。Firefoxを選ぼう。）というフレーズが見える。ちなみに、ここでいうindependenceだが、既に何かに支配されている状態を前提にするときは「独立」と訳すのが適当だろうが、支配されるのを防ぐという文脈では、依存しないという趣旨で「自立」と訳すべきだと考えるので、本記事ではそのようにしている。

上記のようなMozillaのメッセージを強く印象づけるのが、キャンペーン用動画だ。0:50ころからの台詞は、個人的なfreedomと集団的なindependenceに焦点を当てたものになっている。日本語字幕は字幕という表現上の制約の中で翻訳されたものなので、私訳を付す。

Firefox: Choose Independent - YouTube

（原文）
Choosing Firefox isn't just choosing a browser.
It's a vote for personal freedom.
It's how we keep our independence online burning bright.

（日本語字幕）
Firefoxを選ぶこと。それは単なるブラウザ選択ではありません。
個人の自由を宣言することでもあります。
みんなのインターネットを守り、より明るく輝かせるために。

（私訳）
Firefoxを選ぶことは、単にブラウザを選ぶことだけにとどまりません。
個人の自由に賛意を示すことであり、私たちがオンライン上の自立性を明るく輝かせ続けるための手段でもあるのです。

Mozillaが念頭に置いているWebの状況については、Andreas Gal氏（Mozilla Corporation CTO）が"10 Years of Firefox and Innovation for the Web Platform"という記事の中で、簡潔に指摘している。

10 years ago, Mozilla started a long journey to set the Web free of Microsoft’s proprietary control, and today we have largely achieved that goal. The next phase of the struggle for an open Web is mobile where a new duopoly has arisen: iOS and Android.

10年前、MozillaはMicrosoftによるプロプライエタリな支配からWebを解放するという長い道のりを歩み始めました。そして今日、私たちはその目標をおおむね達成しました。オープンなWebのため次に取り組むべき分野は、モバイルです。そこでは、iOSとAndroidという新しい複占が生まれています。

つまり、オープンなWebを守るためには、常に選択肢が確保されている必要があるけれども、そうした選択肢は、現に多くの人に選択されているという事実によって支えられなければ、長くは保たない。Firefoxを選ぶことでWebの自由を支えてほしいというのが、Mozillaのいわんとするところだと思われる。筆者も、オープンなWebを守ることが大事だという点に関しては全く異論がない。

新戦略のリスク

"Doing good is part of our code."のフレーズに象徴されるように、Mozillaコミュニティが価値を担うことは、これまでも行われてきた。

しかし、Firefoxに価値を担わせるべきだという意見が出てきたのは、それほど古いことではない。Gervase Markham氏（Mozilla Corporation Governator）が2011年7月に発表した記事"Mozilla’s Competitive Advantages"では、Chromeがシェアを伸ばしてきていることを踏まえ、製品を「新しく輝かしいもの」として宣伝するなら、ユーザーはより新しく、より輝かしいものを求めていくことになるので、コミュニティ、理想を掲げていること、友好的支持といった強みをアピールすべきだとの主張がなされている。逆にいえば、この時期までFirefoxは、その性能を中心にアピールしていたわけだ。

Internet ExplorerがWebで圧倒的なシェアを誇っていた時代、ほかのブラウザを選べること自体が、ユーザーにとっての自由だった。そして、ほかのブラウザを選ぶにあたって、いちいち動機を問われることはなかった。もちろん、ユーザーの中にはWebの自由を体現するものだと考えてFirefoxを選んだ人もいただろうが、多くは、シンプルで使いやすいとか、アドオンが魅力的だといった理由でFirefoxを選んでいたのではないか。

選択肢があるという状況自体が自由を意味し、ユーザーがさまざまな動機でFirefoxを選んでいることは、現在においても何ら変わりがない。にもかかわらず、Firefoxを選ぶことに価値を結びつけるとすれば、排他的な対外的イメージを生じることにならないだろうか。

考えてみてほしい。たとえば、Internet ExplorerやChromeやSafariを、標準でインストールされているという理由で使い続け、あるいは自らダウンロードして選ぶことは、それだけで不自由と依存を選んだことになるのだろうか。Android OSやChromiumの開発に外部から貢献したら、Googleの支配に手を貸したことになるのだろうか。もちろん、Mozillaがそのような極論を述べているわけではないが、Firefoxを選ぶことが自由と自立を選ぶことになると位置づければ、必然的に別の選択（不作為を含む）にネガティブな意味を付与することになる。

そうして生じた排他的なイメージは、キャンペーンの意図に反して、ユーザーを遠ざけることになりかねない。だからこそ、Mozillaコミュニティが価値を担い、そのような価値を実現する目的でFirefoxを開発する一方で、Firefox自体は価値中立的なソフトウェアであり続けるという役割分担が重要になってくる。

また、Firefoxが直接に価値を担うとすれば、開発に制約が生じ、エンジニア主導の開発体制が変質する可能性すらある。別の分野における最近の例を挙げると、2014年9月、文字コード規格であるUnicodeについて、顔や人体の絵文字が明るい肌色で実装されている現状への対策として、色調を変化させる符号が提案されたという。おそらく、技術的な観点からすれば、この提案は規格を複雑にし、新たに実装するコストを生じさせることになるし、過去の実装との互換性にも影響するかもしれない。とはいえ、文字が文化的に重要なものであることは誰も否定できないため、平等性の実現が優先されることになるだろう。

Mozillaコミュニティに関しては、「JavaScriptの父」Brendan Eich氏がMozilla CorporationのCEOの座を追われた事実も見逃せない。ニューヨーク・タイムズWeb版の記事"Personality and Change Inflamed Mozilla Crisis"にまとめられているとおり、Eich氏は、2008年、同性婚を禁じるカリフォルニア州憲法の改正条項（通称Proposition 8）に賛成して1,000ドルを寄付したのだが、2014年になってその行動を問題視された。Mozilla Corporationの方針ではなく、CEO個人の政治的信条が同性愛に不寛容なものであったこと自体が強い批判にさらされたのは、Mozillaコミュニティが一定の価値を担う以上、その中心にあるMozilla Corporationはその先頭に立たねばならず、同社の代表であるCEOもまた、そのような価値にふさわしい人物でなければならないと考えた人が少なくなかったからだろう。

Eich氏の身に起こったことは、Firefoxの開発プロセスにおいても起こりうる。FirefoxはWebの自由と自立を担っているのだから、ある機能を実装すべきだとか、実装するのはふさわしくないといった議論が沸き起こり、主要開発者たちにもコントロールできなくなる日が来るかもしれないのだ。やはり、Mozillaコミュニティが価値を担い、Firefox自体は価値中立性を保つ形にとどめておくほうが賢明ではないだろうか。

Pocketとは

Pocketは、サンフランシスコに本社を置くRead It Later, Inc（以下RIL社）が提供するアプリケーションおよびサービス。RIL社による概要の説明は、以下のとおり。

Pocket は、面白い記事やビデオ、その他のウェブコンテンツを「後の楽しみに保存しておきたい」という人のため、ネイト・ウィーナーにより2007年に設立されました。一旦 Pocket に保存されると、コンテンツのリストが—携帯電話やタブレット、コンピュータなど、どんなデバイスでも見れるようになります。順番待ちの時、ソファでくつろぎ中、または通勤時や旅行時—など、オフラインであっても閲覧可能です。

世界をリードする弊社の「後で読む」（save-for-later）サービスは現在、1,200万以上の登録ユーザーを抱えており、Flipboard や Twitter、Zite など、500以上のアプリと連携しています。また、iPad や iPhone、Android、Mac、Kindle Fire、Kobo、Google Chrome、Safari、Firefox、Opera、Windows など、主なデバイスやプラットフォームに対応しています。

Firefox向けにはアドオンやSocial APIボタンが提供されている。また、最近デザインが刷新されたWebアプリは、2014年3月時点で日本語に対応済みである。なお、日本はRIL社にとって米英に次ぐ市場だという。

統合の具体的な内容

Firefox 38.0.5のリリースまで時間が限られているため、最初の段階における統合は基本的なレベルにとどまる。具体的には、ツールバーにPocketボタンが設置され（Bug 1155523）、コンテキストメニューに「Pocketに保存する」旨の項目が（Bug 1155518）、ブックマークメニューに「Pocketのコンテンツを見る」旨の項目が（Bug 1155519）、それぞれ追加される。

統合されたPocketは、デフォルトで有効化されるため、既にPocketのアドオンやSocial APIボタンがインストールされている場合、アドオン／ボタン側が自動で無効化（または削除）されるようだ（Bug 1155521）。ただ、アドオン版Pocketの機能を当初から網羅することは難しいとみられ、既存ユーザーはアドオンを再度有効化する必要が出てくるかもしれない。

もともと、Mozillaはローカル版「あとで読む」機能というべきリーダーモードをAndroid版Firefoxに実装しており、この機能をデスクトップ版にも実装して、保存リストをデバイス間で同期可能にする予定だった（Bug 1123529）。まさにFirefox 38.0.5でデスクトップ版リーダーモード機能を有効化すべく、開発も続けられていた（Bug 1148098）。今回の急な方針転換は、Mozilla Corporation（以下Mozilla Corp.）とRIL社との合意が最近になって行われたことを示すものだろう。

Pocketの統合が優先されるため、リーダーモード機能の開発はひとまず中断されることになるが（Bug 1155515）、これまでの開発が全く無駄になったわけではない。将来的にPocketで保存したコンテンツをローカルでも閲覧できるようにする際、デザインを調整しつつ機能が再利用されるためだ（Bug 1155536）。

統合によるメリット

今回の統合におけるRIL社側のメリットは明らかだ。１億人近いFirefoxのアクティブユーザーを一部でも取り込めれば、ユーザーベースを現在の1200万から大きく拡大できる。サービスの利用者が増えれば、プレミアム版に登録するユーザーも増えることだろう。もっとも、利用者が急激に増加することで、サーバーに過負荷がかかることも懸念される。このあたり、正式発表時に何らかの言及があるのかもしれない。

他方、Mozilla側のメリットとして、評価の確立された「あとで読む」サービスを直ちにユーザーに提供できることが挙げられる。また、上記Bug 1155523において、FirefoxアカウントによってPocketにログインできるようにすると説明されており、今回の統合は、Firefoxアカウントを普及させる方策でもあるわけだ。他社サービスの統合にまで踏み込んだ割には、Mozilla側のメリットが小さいようだが、検索サービスの場合と同様に、Mozillaに対価が支払われると考えれば納得がゆく（こちらは発表時にも言及はされないだろうが）。

Mozilla Corp.の内部ですら開発者らにRIL社との交渉経過が伝わっていなかったという経緯については、開発のあり方として一抹の不安を覚えるものの、Pocketの統合によってFirefoxの利便性が高まる点は、素直に喜びたい。

（15/05/17追記）
MozillaやRIL社から提携に関するアナウンスはないが、現在公開されているFirefox 38.0.5 BetaではPocketの統合が有効化され（リリースノート）、ユーザーが利用可能な状態になっている。

一時はローカライズなしで投入されるという話もあったのだが、通常の手順を踏まず、翻訳された文字列をハードコードする方法によって、英語以外に、ロシア語、日本語、スペイン語およびドイツ語をサポートした（Bug 1162283）。

なお、既存のPocketアカウントがある場合に、Firefoxアカウントでログインするとどうなるのか試してみたが、少なくとも登録しているメールアドレスが共通だと既存のアカウントにログインするようだ。

（15/06/03追記）
Firefox 38.0.5がリリースされ、当初の予定どおりPocketは本体に統合された（Firefox がオンライン生活のコントロールを可能に | Mozilla Japan ブログ）。

上で記載した内容をアップデートしておくと、既にPocketのSocial APIボタンを利用している場合は、アンインストールされて新しいウィジェットが導入されるのに対し、Pocketのアドオンを利用している場合は、アドオンが優先される（Bug 1155521のパッチ参照）。また、リリースノートに記載された「リーダーモード」は、リーダービューのみで、リーディングリストを含んでいない点がAndroid版Firefoxと異なっている。つまりPocketと重複する機能は省かれているわけだ。

Mozilla Corp.とRIL社との提携については、Pocketのブログで発表された（Pocket is Now Built Into Firefox!）。記事の末尾の署名を見ると、CEOであるNate Weiner氏が記載したものとみられるが、同記事によれば、今後、Pocketアドオンはメンテナンスのみが行われることになる。

明示的に会社間の関係という形式をとっていないこともあり、発表からは提携に伴う対価の支払いがどうなっているのかをうかがい知ることはできないが、この点に関しては、PE HUBの"Pocket picks up $7 mln in NEA-led round"に引用されたRIL社のプレスリリースが興味深い。同社が2015年4月に700万ドルの資金調達を行ったことに関し、その使途を開発チームの拡大およびパートナーとの統合強化と述べているからだ。資金調達の時期からみて、この700万ドルの一部がMozilla Corp.に支払われたとみてよいのではないか。

ページの読み込み速度およびメモリ使用量

10のWebサイトを同時に開いて、読み込み中であることを示すアイコン（throbber）が消えるまでの時間を手動で計測した（秒数の小数点以下は切上げ）。同時に、10サイトを表示させた場合と、単サイトを表示した場合のメモリ使用量もチェックした。

具体的な手順は、次のとおり。以下の10サイトをその記載順にフォルダ内にブックマークしたバックアップファイル（FirefoxではJSON形式、ChromeではHTML形式）をインポートし、「タブですべて開く」（Chromeでは「すべてのブックマークを開く」）で10サイトをいっせいに読み込む。throbberが消えるまでの時間を計測し、完了したらFirefox（Chrome）のホームページは閉じ、各タブをクリックしてWebページを実際に画面に表示させる。つまり最後に表示されるのはWikipedia（日本語版）になる。

• 日本マイクロソフト / Apple / 食べログ
• Amazon.co.jp / YouTube / NHKオンライン / 朝日新聞デジタル
• はてな / Yahoo! JAPAN / Wikipedia（日本語版）

1分間そのまま放置した後、新しいタブを開いてabout:memoryを呼びだす。Firefoxでは"Show memory reports"のMeasureボタンをクリックし、Main Processのresidentの値を見る。もっとも、これだけではChromeとの比較ができないため、同時にChromeのabout:memoryからもFirefoxのプロセスのPrivate Memoryの値をチェックする。

そして、「他のタブをすべて閉じる」でYahoo! JAPAN以外のWebページはすべて閉じる。1分間そのまま放置した後、再び新しいタブを開き、about:memoryを呼びだしてMain Processのresidentの値を見る（ChromeではPrivate Memoryの値をチェックする）。Firefox（Chrome）をいったん終了させ、再起動後に上記10サイトを同じ手順で開いて、throbberが消えるまでの時間を計測する。一連の手順を実行した結果がこれだ。

読み込み速度についてみると、Firefox 38において1回目の読み込みに要する時間が短縮されている。これは、新しいHTTPキャッシュ（cache v2）を導入したことによるものだろう。他方、2回目の読み込みに要する時間は変わらないが、改善の余地があることはChromeとの比較から明らかだ。

メモリ使用量は、Firefox 38において増加傾向にある。世代別ガベージコレクション（Generational GC）も導入済みだが、メモリの解放には限界があるのかもしれない。これに対し、Chromeは派手な結果が出ている。Firefoxの数値と比較するときは、カッコ内の数字を参照してもらいたいのだが、10タブを開いたときのChromeのメモリ使用量は、Firefoxの倍まではいかないにせよ、かなり多い。ところが、タブを閉じていくと一転してメモリ使用量が激減するのだから面白い。ひょっとすると、ディスクキャッシュを用いた再読み込みの速度に自信があるので、メモリキャッシュは少なくてもよいと割り切っているのだろうか。

レイアウトおよび描画処理

JavaScript/DOM処理

asm.js

Emscriptenプロジェクトの一環として公開されているベンチマーク・スイートEmbenchen v0.0.2を利用して、asm.jsの処理性能を見る（参照：asm.js performance improvements in the latest version of Firefox make games fly! ?）。このベンチマーク・スイートは、マイクロベンチマークとマクロベンチマークから構成されるが、性能の指標としては実環境に近い後者が重要となるので、本記事でもマクロベンチマークの結果を掲載する。なお、数値が小さいほど高速である。

OdinMonkeyを搭載したFirefoxの圧勝、というわけにはいかなった。Chromeもさほど規模の大きくないasm.jsコードであれば、ある程度高速な処理が可能であるらしい。

次に、同じくEmscriptenプロジェクトの一環として公開されているベンチマーク・スイートMASSIVE v1.1を走らせてみよう。このベンチマークは、大規模なasm.jsコードに特化しており、Poppler、SQLite、LuaとBox2Dのコードをベースに、スループットだけでなく、読み込み時間や読み込み中の応答性、パフォーマンスの一貫性なども計測対象とするものだ。

こちらは大差がついた。Mozillaが開発に力を入れている証だろう。

総合的なベンチマーク・スイート

総合評価

前回Firefox 31を検証した際、やや物足りない感があり、アーキテクチャの革新に期待したいと述べたわけだが、Firefox 38はその期待に応える仕上がりだと評価できる。いろいろな角度からテストしてみたが、ほぼ全面的にFirefox 31よりも好成績となっており、特にOctane 2.0やPeacekeeperでChrome並みのスコアが出たのは驚きだった。

一般的なWebアプリの処理性能という観点からすると、Chromeと互角に渡り合うのはやや苦しいものの、WebGLと大規模なasm.jsコードという組み合わせでは、おそらくFirefoxが最速となるはずだ。ゲーム・コンテンツがまさにその組み合わせであるのは、偶然ではあるまい。MozillaがFirefoxをWeb上で最高のゲーム・プラットフォームにすべく開発を続けてきたことが、実を結びつつある。

次のESRは、Firefox 45がベースとなる。この時点で、リリース版でもマルチプロセス化（コード名Electrolysis）が実現されているだろうし、64bit版の提供についても進展があるだろう。それでなくても、Firefox Nightly 40はリリースサイクルの後半、動作が高速で快適だった。Firefox 45までの間にどこまで良くなるか、今から楽しみである。