Firefox 51から53までWebゲームプラットフォームとしての機能を段階的に強化（再追記あり）

MozillaはこれまでもFirefoxをWebゲームの強力なプラットフォームにすべく改良を重ねてきたが、Firefox 51以降の3バージョンの間にそのステージを1段階引き上げる。3Dの表現力だけならPlayStation 3/Xbox 360世代に匹敵する水準となり、ゲームのロードから開始までの時間が短縮され、動作の安定性も向上する。具体的にどのような変化が起きるのか紹介しよう。

Firefox 51

最近リリースされたFirefox 51では、WebGL 2が初期設定で有効化された。これを踏まえたプレイアブルなデモが、PlayCanvasの"After the Flood"である。大洪水後の荒廃した未来の町並みが美しいグラフィックスで描写されており、2012年3月に公開されたBrowserQuestと比べると、表現力の進歩を実感できるだろう。

www.youtube.com

WebGL 2はOpenGL ES 3.0がベースになっており、WebGL 1（OpenGL ES 2.0ベース）とは緩やかな後方互換性を保っている。WebGL 2の処理パイプラインの構造はWebGL 1のものをほとんど踏襲しているが、新機能の追加によって3D APIの表現力が増強されている。たとえば複数のテクスチャに対し同時に書き込みができるようになり（Multiple render targets）、複数のインスタンスを1回の描画命令で描画することが可能になった（Instanced geometry drawing）。また、3Dテクスチャや2Dテクスチャ配列がサポートされ、頂点シェーダで計算した結果を頂点バッファオブジェクトに書き込むこともできる（Transform feedback）。

Mozillaは今後、WebGL 2 APIのパフォーマンスを向上させるほか、一部の制約を緩和するなどAPI自体も洗練させていくとしている。

参考：WebGL 2 lands in Firefox ★ Mozilla Hacks

参考：WebGL 2.0の概要 - Qiita

Firefox 52

Firefox 52ではWebAssemblyが初期設定で有効化される予定だ。JavaScriptのサブセットにすぎないasm.jsとは異なり、WebAssemblyはバイナリフォーマットを採用しているのでコンパクトだ。2016年3月時点で、そのサイズは非圧縮のasm.jsよりも42％小さいとされていた。現在はさらに差が開いている可能性がある。

パフォーマンスの面でも、WebAssemblyはasm.jsよりも良好なスループットを達成している。また、コンパイル時間の短縮も図られており、Unityのテストで3420ミリ秒から1492ミリ秒になったという話もある（Bug 1317033）。

このWebAssemblyに関連して、Large-Allocation Headerという機能が32bit版向けにFirefox 52で有効化されるかもしれない（Bug 1331083）。この機能はマルチプロセス化（e10s）を前提にするもので、ドキュメントにこのヘッダが付いていると、読み込み予定のページに独立したプロセスが割り当てられる。そのプロセスでは大量の連続的なメモリを確保できるので、WebAssemblyベースのゲームを読み込む際に有効であるというわけだ。

以上とは別に、Firefox 52ではSharedArrayBufferおよびAtomics APIが初期設定で有効化される（Bug 1312446）。SharedArrayBufferは、スレッド間で共同利用できるバッファを作ることができるというもので、そのバッファの操作やスレッドの制御を行うのがAtomics APIだ。

SharedArrayBufferが導入された背景については、A Taste of JavaScript’s New Parallel Primitives ★ Mozilla Hacksに説明がある。その和訳であるJavaScript の並列処理機能を味見してみる | Mozilla Developer Street (modest)から引用しておく。

これらに代表される JS （注：JavaScript）の適用範囲の拡大は、パフォーマンスの驚異的な改善によって可能となりました。それは JS エンジンに実装された Just-in-Time(JIT) コンパイラや、より高速な CPU によってもたらされました。

しかし、JIT による実行速度向上のスピードは低下しつつあります。また CPU 速度の改善はほとんど頭打ちになっています。CPU の高速化に代わる手法として利用されているのは、複数の CPU（実際は CPU のコア）の利用です。これは携帯電話からデスクトップにいたるまで広く利用され、ローエンドの環境を除けば、最低でも 2 つ以上の CPU が利用できるようになっています。このような状況でプログラマがプログラムの性能を向上させたいなら、複数のコアの並列利用を選択するでしょう。これは Java、Swift、C#、C++ のようなマルチスレッドプログラミングが可能な言語で書かれたネイティブアプリの話ではありません。Web Worker と、その遅いメッセージパッシング機構、そしてデータコピーの回避手段がほとんどないという、複数の CPU を利用するには極めて制限された機能しか持たない JavaScript での話です。

つまりは JS には問題があるのです：Web 上の JS アプリケーションが、ネイティブに代わる有力な選択肢であり続けるためには、JS を複数 CPU の上で動作させられるような機能を JS に持たせなければなりません。

要するにSharedArrayBufferは、PC側の複数CPUコアを利用して、並列に計算させることでJavaScriptの処理速度を向上させるための仕組みだ。重いゲームを動かす際に力を発揮することは、いうまでもない。

参考：SharedArrayBufferとAtomics APIについて - JS.next

Firefox 53

Firefox 53では、別記事に書いたとおり、適格性のあるWindowsユーザーに対し軽量インストーラ（スタブインストーラ）が初期設定で64bit版をインストールするようになる（Bug 797208）。64bit版はOOM（out of memory：低メモリ）クラッシュが減って安定性が向上するだけでなく、パフォーマンスも向上することがベンチマーク結果から明らかになっている。

Windows版でQuantum Compositor（旧名GPUプロセス）が初期設定で有効化される点も見逃せない（Bug 1330554）。Geckoのcompositorに独立したプロセスを割り当てるこの機能は、GPUドライバが原因のクラッシュを45％も減少させる。64bit版である場合やDirect3D 11を使用する場合には、クラッシュ率を全般的に引き下げる効果も認められている。

（17/02/12追記）
Firefox 51以降の動きを紹介する主旨なので本文では触れていないが、2016年中にWeb Audio APIの仕様変更に追随するなど、オーディオ面でも性能は向上している。

（17/03/09追記）
Firefox 52の初期設定でWebAssemblyが有効化された（Bug 1342060）。他方、Large-Allocationヘッダは、Firefox 53（32bit版のみ）で有効化される見通しである。

（17/03/13追記）
WebAssembly + WebGL 2.0を駆使したZen Gardenデモが公開されている。高精細な3D画面が次々に展開されていく美麗なデモではあるが、ファイルサイズが約100MBあり、動作にかなりのマシンパワーとメモリを必要とする。Webの最先端を示すものといえよう。

www.youtube.com

その一方で、軽量インストーラが初期設定で64bit版をインストールするようになる時期は、Firefox 55へと後退した。64bit版でFlashの非同期レンダリングのサポートが遅れていることが原因である。ただ、Firefox 53のWindows向けインストーラでは、オプション画面でユーザーが32bit版と64bit版のいずれをインストールするか選択できる。

（17/05/03追記）
Firefox 52/53ではSharedArrayBufferおよびAtomics APIの有効化が見送られた（Bug 1342095、Bug 1354160）。投入はFirefox 54となる。

（17/05/14追記）
SharedArrayBufferおよびAtomics APIの有効化はFirefox 55へと延期された。

2017年10月上旬までにWindows向け64bit版Firefoxの自動アップデートが開始（追記あり）

Mozillaは、米国時間の2017年3月7日にリリース予定のFirefox 52でAdobe Flash以外のプラグインのサポートを終了させた後、64bit版へのシフトを本格的に進めていく。

同年4月18日にリリース予定のFirefox 53では、適格性のあるWindowsユーザーに対し軽量インストーラ（スタブインストーラ）が初期設定で64bit版をインストールするようになる（Bug 797208）。適格性のあるWindowsユーザーとは、64bit版Windows 7以降を使用し、3.8GB以上の仮想アドレス空間にアクセス可能なハードウェアを使用しているユーザーのことをいう。物理メモリは64bit版Windows 7以降の動作環境である2GBを満たしていればOK。なお、OS X（macOS）向けFirefox 53は、Intel 64bit版に一本化される（Bug 1295375）。

そして、Firefox/Win64 - MozillaWikiおよびその改版履歴によれば、適格性のあるWindowsユーザーが32bit版Firefoxを使用している場合、2017年8月8日にリリース予定のFirefox 55か、同年10月3日にリリース予定のFirefox 56で、64bit版への自動アップデートが行われる。

自動アップデートの時期がFirefox 55と56のいずれになるかは、予想の難しいところだが、最近のMozillaのアグレッシブな姿勢からすると、Firefox 55のほうが可能性が高そうだ。もっとも、Firefox 55の時点では対象ユーザーの30％程度にアップデートの提供をとどめておき、発見された問題を潰したうえで、Firefox 56において100％に引き上げるといったことも考えられる。いずれにせよ、おそらく2017年末には、64bit版Firefoxのユーザー数が32bit版のそれを上回っているだろう。

（17/01/21追記）
本記事執筆後、Firefox/Roadmap - MozillaWikiにおいて自動アップデートの時期がFirefox 55になると発表された。

（17/05/09追記）
本文で記載したプランは変更されている。Firefox/Win64 - MozillaWikiの最新情報によれば、軽量インストーラ（スタブインストーラ）が初期設定で64bit版をインストールするようになるのは、Firefox 55からである。また、64bit版への自動アップデートは、Firefox 56.0.1のリリースとともに行われる。ただ、Firefox 56のリリース時期が9月26日に前倒しされたため、10月上旬までに自動アップデート開始という点は実現されそうだ。

（17/09/18追記）
最新の情報をMozillaがWindows向けFirefox 56.0に対し64bit版56.0.1への自動アップデートを提供予定 - Mozilla Fluxに記載したので、そちらも併せて参照してほしい。

関連記事

• Windows向けFirefox 52で64bit版が主役に 2017年後半には自動アップデートも提供へ - Mozilla Flux

Chrome向けFeedlyはてブ拡張をFirefoxで使う方法

2016年末にFeedlyをはてブ対応させるChromeエクステンションがChromeウェブストアで公開された。Otchy氏が自作のユーザースクリプトを拡張機能化したもので、Feedlyのリスト画面にはてなブックマークの数を表示してくれる。

ユーザースクリプト版がFeedlyの仕様変更に伴って動かなくなっていたので、開発が再開されたのは嬉しい限り。しかし、Chrome向け拡張機能なので、これまでみたいにFirefoxにGreasemonkeyを入れて使うというわけにはいかない。何とか動かす方法はないものか。

Chrome Store Foxified（以下CSF拡張）を使うのがよさそうだ。この拡張機能をFirefoxにインストールした状態で、Feedly はてブ - Chrome ウェブストアを開く。すると、ふだん右上隅に「CHROME に追加」と出るところが、「ADD TO FIREFOX」へと変わっているはずだ。これをクリックする。

CSF拡張のメニューが出てくるので、自分が使用するFirefoxのチャンネルを踏まえて選択する。たとえばNightly／Auroraチャンネルであれば、「Save Unsigned Addon to File」を選択し、保存したXPI形式のファイルをアドオンマネージャからインストールすればOK。予めxpinstall.signatures.requiredの設定をfalseに変えておくのを忘れずに。Mozilla Add-ons（AMO）からデジタル署名を得ていない拡張機能を使えるようにしておく。

Beta／リリースチャンネルの場合、もう少し手間がかかる。AMOのデジタル署名が必須なためだが、CSF拡張には「Sign Add-on then Install」という選択肢がちゃんと用意されている。ただし、AMOへのログインが必要なので、Add-ons for Firefoxのページの最上段に「ユーザー登録 / ログイン」とある箇所から事前にログインしておく。ここで要求されるのはFirefoxアカウント。Firefox Syncを使っているなら、既に持っているはずだ。ちなみに、AMO独自のアカウントは2016年8月31日をもって廃止された。

CSF拡張が素晴らしいのは、AMOから非公開のアドオンとしてデジタル署名を取得する処理を、自動で行ってくれる点。しかも、UUIDの衝突を回避する仕組みを備えており、ユーザーはAMOに近い感覚でChromeウェブストアの拡張機能をインストールできる。

Feedlyはてブ拡張がインストールできたら、Feedlyを開いてみよう。はてなブックマークの数が表示されているはずだ。筆者はFirefox 50.1.0で動作を確認した。なお、当然ながらアドオン作者の保証外の行為だし、自動アップデートもできない。

作者のOtchy氏は以下のように述べているが、ECMAScript Next support in Mozilla - JavaScript | MDNのとおり、FirefoxでもES2016のサポートは着実に進んでいる。Webの互換性が確保されている状況も、素敵な事ではないだろうか。

もともと書いていたユーザースクリプトが動かなくなって、エクステンションが必須だな、となった後もしばらく重い腰を上げられなかったのは、やはり上記で説明したような諸々が面倒そうだなー、と思っていたからでした。その重い腰を上げるきっかけになった一つは、そう、Chrome だけがターゲットという事は、「生の ES2016 で書いて問題無い」という事に気づいたからです。何と素敵な事でしょう。

超最低限の Chrome エクステンションを開発しウェブストアで公開するまでの手順 - Qiita

FirefoxのWindows XP／Vistaサポートが2017年9月で終了へ（追記あり）

Windows XP／Vista上のユーザーが通常版のサポートを受けるのは、Firefox 52で最後となり、その先は法人向け延長サポート版（ESR）に切り替わってサポートが続く（Bug 1318922）。つまり、Firefox 53ではなくFirefox ESR 52.1へと自動アップデートされる。

ESRに移行した後のXP／Vistaのサポート期間について、Mozillaは2016年12月23日（米国時間）、2017年9月までとする旨を発表した。これを受けて、重要: Firefox は Windows XP および Vista のサポートを終了します | Firefox ヘルプには、次のように記載されている。

私たちは、2017 年 9 月まで Windows XP および Vista のユーザー向けにセキュリティの更新を提供する予定です。しかし、これらのユーザー向けの更新には新機能が含まれません。私たちは、2017 年の中頃に、まだ Windows XP と Vista を使用しているユーザーに対して最後のサポート終了日をお知らせします。

Firefox ESR 52.3が2017年8月8日に、52.4が同年10月3日にそれぞれリリースされる予定となっており、上記発表の趣旨は、ESR 52.3を最後にWindows XP／Vistaのサポートを打ち切るということだろう。ただし、Mozillaは2017年半ばの時点でXP／Vista上のユーザー数を再評価し、サポート終了日を最終的にアナウンスするとしている。これは、XPにつき延長の余地を残すものだ。

筆者は、過去の記事で、ESRのサポート期間の途中でOSのサポートが打ち切られる可能性はまずないと述べたが、見事に予想を外してしまった。Mozillaがこれまでの慎重な姿勢を崩し、XP／Vistaのサポート期間を当初の計画よりも前倒しで終わらせることにしたのは、QuantumプロジェクトやWebExtensionsへの急激なシフトと無関係ではないだろう。Mozillaは選択と集中の傾向を強めており、たとえ一部のユーザーを切り捨てることになっても、Firefox／Geckoの刷新に注力して、新しいユーザーを獲得するほうに賭けるという態度が顕著になりつつある。要するにXP／Vistaのサポートは、選択されなかったのである。

この勢いだと、Firefox 52のリリースから1年後のFirefox 59では、Windows向け32bit版のサポートが終了するかもしれない。

（16/12/28追記）
Mozilla Japanの方から以下のとおりコメントを頂いた。

いや、quantum関係ないと思うけど。third party libの話が一番でかい https://t.co/VBttzqjEcC

— Makoto Kato ︎︎ (@makoto_kato) 2016年12月25日

chromium sandboxとかICUとかはout of dateなversionを使う必要性がある以上、それらのセキュリティホールのメンテナンスをしないといけないし、ビルドインフラでのXPの自動テストも維持しないといけないとかいろいろあります

— Makoto Kato ︎︎ (@makoto_kato) 2016年12月28日

（17/10/05追記）
Update on Firefox support for Windows XP and Vista | Future Releasesが2017年10月4日付けで公開された。それによれば、Firefox ESRにおけるWindows XP/Vistaのサポートは、ESR 52のサポート終了と一致することになった。2018年6月25日まではサポートが続く。

Project Tofinoが遺したもの

Project TofinoからBrowser Futures Groupへ

Mozillaが2016年4月に開始したProject Tofinoは、Webブラウザのユーザーインターフェイス（UI）のコンセプトが仮に2016年に作られたらどうなるかを実験するプロジェクトである。当初は3か月の期間限定とされていたが、実際には延長されて8月頃まで続いていたようだ。プロジェクトの総括が公表されたのは、11月半ばになってからである。トップを務めるMark Mayo氏は、(Re)defining the Tofino Project – Project Tofino – Mediumの中で、プロジェクトがBrowser Futures Groupの研究へと発展的に解消していく旨を述べる一方、具体的な成果を示さなかった。

では、Project Tofinoは失敗だったのだろうか。評価を下す前に、このプロジェクトがどのように進展していったのかを見ておきたい。もともと、FirefoxのUXチームには、UIの刷新を目指すFawkesというプロジェクトがあった。Tofino自体、その発展型にあたる。FawkesのWindows 10向けモックアップを眺めれば、Microsoft Edgeの影響を受けていることは明らかだ。現在のFirefoxが採用するAustralisはChromeの影響を受けたデザインなので、どうやらMozillaは開発時点で最先端のデザインを応用するのが好みらしい。Tofinoの初期段階で、プロジェクトチームがこのFawkesのモックアップに近いデザインを実験したことが確認できる。

ところが、本来ならプロジェクトも終盤に差しかかっているはずの6月上旬になって、これまでのデザインを白紙に戻すという決定が実行に移された（Tofino Project Goals Update – Project Tofino – Medium）。そして、プロジェクトチームは7月上旬に至っても、コンセプトを紙に起こし、簡単なモックアップを作る作業を繰り返していた（Iterations – Project Tofino – Medium）。この一連の動きは当時情報を追っていて謎だったのだが、今思えばこの時点で既に、プロジェクトの最後にデザイン案を大々的に打ち出すことは諦めていたのだろう。

おそらく、プロジェクトチームは、UIの抜本的な改良のためには何（what）を作るかと同時に、どう（how）作るかを同時に考えねばならず、一定の結論を得るにはかなりの試行錯誤が必要だと判断するに至ったのだ。ブラウザはユーザーにとってどのような存在であるべきなのか、そのためにはどんなデザインや機能が必要で、標準化された技術を用いてそれらを実現させるためには、どうしたらいいのか。また、UIに関してユーザーの「慣れ」の問題は避けて通れない。新たなデザインをどうやって受容してもらうかも重要だ。Tofinoはそうした検討課題について、解決の方向性を見極めるものとして終わったのではないか。そして、実際の結論はBrowser Futures Groupの研究に委ねることにしたのだろう。

将来のFirefoxに適用されるアーキテクチャ

Tofinoが見出した方向性の1つは、ブラウザをコンポーネントの集合と捉えずに、疎結合されたレイヤーの集積と捉えるというものだ。Engineering update on Tofino – Project Tofino – Mediumで説明されているところによれば、レンダリングエンジンは自己完結的になり、アプリケーションの他の部分とは、限定されかつ明確に定義されたポイントにおいて統合される。

そして、ユーザーの履歴やブックマークといったプロファイル情報は、ユーザーエージェントサービス（UAS）と呼ばれる独立したプロセスが管理し、ブラウザのメインプロセスやウィンドウなどは、すべてこのUASに接続することになる。接続方法は、HTTPとWeb Socketsだ。また、UASはクラウドと繋がって、ユーザーにとってのおすすめ情報を取得する。ここでは、ブラウザがユーザーの代理人として、適切に判断して行動するというコンセプトがある。

UASが管理するプロファイル情報は、Datomishと呼ばれるデータベースに格納される。DatomishはDataScriptの派生物で、Datomicデータベースシステムのアイデアを、ClojureScriptではなくRust言語で実現したものだ。持続的なストレージを前提にSQLite上に構築され、スケーラビリティに優れ、Firefoxへのデプロイも容易だという（Introducing Datomish, a flexible embedded knowledge store – Project Tofino – Medium）。

Mark Mayo氏の総括が重要なのは、こうしたコンセプトや要素技術が、将来のFirefoxに適用されると明らかにした点だ。Browser Futures Groupが行う研究は、年単位ではなく月単位だとしており、その後は当然実装の段階に移ると考えられる。別の言い方をすれば、MozillaはQuantumプロジェクトでGeckoを大改造するように、Firefoxのフロントエンドも大幅に刷新するつもりなのだ。

FirefoxというMozillaの基幹製品に手を付けるのだから、UIの作り方やパフォーマンスにこだわるのも当然だろう。Tofinoの総括の中で、ElectronとReactを利用したブラウザ構築の限界について相当の紙幅が割かれているのだが、その理由は、仮にMozillaがReactのようなフレームワークを作り、Positronと組み合わせたときに、Firefoxで使いものになりそうか探っていたためだと思われる。結果は、試作品の作成にはよいが、パフォーマンス面で製品化には必ずしも向いていないというものだったようで、Browser Futures Groupの研究においても、その解決策を見つけることが焦点の1つとなっている。

デザイン面での進展

Project Tofinoの総括の中で言及されていないため、あまり知られていないが、新UIのデザインも一応形はできていて、公開もされている。あえて言及しなかったからには、実際にFirefoxに取り込む時点でいろいろ変更があるのだろう。ただ、Tofinoのような集中的な検討の機会は滅多にない。現行のデザイン案がベースになる可能性は高い。

メインUIでは、タブバーにおけるOverview（概要）タブの存在が目を引く。タブブラウザのコンセプトは保たれているが、検索ボックスはなく、ナビゲーション関連のボタンはナビゲーションバーから分離されて左端にまとめられている。逆に右端には、Related Items（関連項目）が表示されている。なお、アクティブでないタブをホバーすると、要約が出るという。

ナビゲーションバー内には、保存ボタンのみが置かれる。保存ボタンを押すと選択画面が現れ、テキストとページ全体のスクリーンショットを保存できる。動画を保存することも可能だ。また、保存内容をまとめて「コレクション」にしておき、そこに追加するという使い方も想定されている。

保存ボタンをホバーすると、共有ボタンが出現する。共有ボタンを押すと選択画面が現れ、WebページをSNSやアプリで共有できるほか、自分宛にメールで送ることも可能だ。

ナビゲーションバーは、検索の起点でもある。現行のスマートロケーションバーと同様に、よく見るページなどが表示されるが、サムネイルをふんだんに使ってわかりやすくなっている。

関連項目は、閲覧中のページと関連する理由ごとに表示が区分けされる。どういった理由で、どんなコンテンツを表示するかは、Context Graphという別プロジェクトで研究中だ。

概要タブでは、現在開いているタブがサムネイルで一覧表示され、コレクションもリストアップされる。タブ一覧は履歴に切り替えることもできる。面白いのは、Archived Tabs（アーカイブされたタブ）という欄があることで、タブは閉じるのではなくアーカイブするもの、という発想に基づいているらしい。また、概要タブ内の情報は、ユーザーが入力した文字列によってフィルタリングが可能となっている。

使用されるサムネイルは、大型のものほど情報量が増え、たとえばAmazonで取り扱われている商品の場合、レーティングまで表示される。

次世代UIの基盤となったプロジェクト

最初の問いに戻ろう。Project Tofinoは、明確な成果を出せなかったという点では成功とは言えないが、未来のFirefoxの姿を素描できたという点では、失敗とは言えない。

11月の総括時点で、Browser Futures Groupのロードマップは策定中とされていた。2016年12月5日から9日まで、ハワイでMozillaのAll Handsミーティングが開かれており、おそらくそこでロードマップについても議論されたはずだ。筆者の予想では、Mozillaは2017年中に要素技術を確立しつつデザインを固め、2018年前半に新UIを製品版に投入してくるだろう。

（16/12/23追記）
本記事執筆後、Firefoxのビジュアル面の刷新を目指すPhoton（光子）というプロジェクトの存在が明らかにされた（Bug 1325171）。