読者です 読者をやめる 読者になる 読者になる

Mozilla Flux

Mozilla関係の情報に特化したブログです。

Firefoxでレガシーなアドオンが使えるのは2017年11月半ばまで

窓の杜で既報だが、The Road to Firefox 57 – Compatibility Milestones | Mozilla Add-ons BlogでWebExtensionsへの移行プランが発表された。周辺情報も交えつつ解説しよう。

まず、今回の移行プランでは、WebExtensions限定化の時期がFirefox 57のリリース時(2017年11月14日:米国時間)であることが改めて確認された。昨年11月の発表以来、影響の甚大さゆえに先送りされるのではとの噂が絶えなかったが、Mozillaはそうした観測を否定した。

また、レガシーなアドオンの定義や、移行対象のプラットフォームが明確化された点も見逃せない。XUL/XPCOMベースやAdd-on SDKベースの拡張機能だけでなく、埋め込み型WebExtensionsと完全テーマもレガシーなアドオンに含まれる。ここに埋め込み型WebExtensionsが含まれるということは、Firefox 57以降、WebExtensions APIのみで構築された拡張機能しか動作が許されないことを意味する。そして、プラットフォームの面では、Thunderbird/SeaMonkey向けのアドオンが対象外であると明言された。逆に言えば、Android版FirefoxはWebExtensions限定化の影響を受けるわけだ。

マルチプロセス化(e10s)との関係

最近のFirefoxは、バージョンアップごとにマルチプロセス機能(e10s)が有効化される範囲を拡大してきている。拡張機能の互換性はe10sの有効・無効を決めるうえで大きな要素だ。Firefox 50の時点では、WebExtensionsベースの拡張機能のほか、作者がe10sと互換性あり(MPC=true)に設定した拡張機能がインストールされている場合にだけ、e10sが有効化されるようになっていたが、Firefox 51になって、ホワイトリストに掲載された700を優に超える拡張機能(Firefox Beta版でのテストを経て問題なしと判断されたもの)も、e10s有効化の妨げにならなくなった(Bug 1329015)。Firefox 52もほぼ同じ基準になるようだ。

移行プランにおけるFirefox 53のリリース時(2017年4月18日:米国時間)の記載は、こうした経過を踏まえたものである。Firefox 53では、作者がe10sと互換性なし(MPC=false)に設定しない限り、e10sは有効化されるのが原則。例外的に、Mozillaが互換性に問題ありと判断した拡張機能がインストールされているとe10sを無効化する。

e10sの原則有効化と歩調を合わせるようにして、Mozilla Add-ons(AMO)ではレガシーアドオンの新規投稿を受け付けなくなる。既存のレガシーアドオンの更新は可能だが、野良アドオンにデジタル署名を付すことができなくなるとみられ、少なからず影響が出そうだ。

WebExtensionsの別プロセス化

移行プランでは、Firefox 54から56までに関する言及は少ない。Firefox本体のcontentプロセスの複数化(e10s-multi)とサンドボックス化の進展によって、レガシーなアドオンに互換性の問題が生じるかもしれないと記載されているのみだ。

だが、この間にWebExtensionsベースの拡張機能はFirefox本体のプロセスから独立して動作するようになる可能性が高い(Bug 1190679)。この拡張機能専用プロセスは、本体よりも強固なサンドボックス化が施される予定である(Bug 1334557)。ただ、Chromeのように拡張機能ごとにプロセスを割り当てることまではしない。

WebExtensions限定化

Firefox 57のリリース時にWebExtensions限定化の措置が執られた後も、AMOではレガシーなアドオンの掲載を続け、作者が更新できるようにする。掲載をいつまで続けるかは現在のところ未定だ。

WebExtensions限定化の措置はNightlyチャンネルから順に投入されていくため、Firefox Nightly 57のユーザーは、より早い段階で措置の影響を受ける。もっとも、Nightly/Auroraチャンネルに関しては、レガシーなアドオンをインストール可能にする設定が導入される可能性が高い。Nightly/Auroraチャンネルにはアドオンのデジタル署名チェックを回避する設定もあるため、AMOからレガシーなアドオンが排除された後も、Firefox本体の設定が残っている限り修正版を野良アドオンとして利用することができそうだ。ただ、Firefox本体に搭載されたe10sとの互換性を保つための仕組み(e10s shim)が削除されるため、本当に古い拡張機能はどうしようもない。

最後に、Mozilla Corp.でAdd-ons Developer Relations Leadを務めるJorge Villalobos氏による今回の移行プランに関するコメントを紹介しておく。

I fully admit the timing was bad. The opportunity and resources to launch WebExtensions came up when we were already into the initial e10s migration process, and the plans for Firefox also shifted in a way that WebExtensions can be the only path forward. We can’t support legacy add-ons for 2 years more because the APIs they rely on won’t exist then. Supporting them for longer only means extending the frustration of constant breakage, both for developers and users.

タイミングが悪かったことは完全に認める。WebExtensionsを起ち上げる機会とリソースが出てきたときには、既にe10sへの移行プロセスが始まっていたし、Firefoxの計画も変わって、WebExtensions以外に進める道はない。依存しているAPIがなくなってしまうので、レガシーなアドオンをもう2年サポートしろと言われても無理なんだ。サポート期間を延ばしても、頻繁に動かなくなってフラストレーションが溜まるだけだよ。開発者にとっても、ユーザーにとってもね。

現在開いているタブの隣に新規タブを開く(Firefox 51以降)

既にはてなブックマークには記録した情報で、Twitterにも流しているが、使っていて便利な機能なのでブログでも紹介しておきたい。

Firefoxのタブバーには、一番右端に表示されているタブの右隣に新規タブボタンがある。「+」のアイコンが目印だ。このアイコンをクリックすると、全タブの最右端に新規タブが開かれる。この「全タブの最右端」というのがくせもので、既に多数のタブがある場合、タブバーがスクロールして新規タブが表示されることになるため、直前まで開いていたタブがタブバーから消えてしまう。

Firefox 51では、Ctrlキーを押しながら新規タブボタンをクリックすることで、現在開いているタブ(以下「アクティブなタブ」)の隣に新規タブが開かれるようになった(Bug 528005)。直前まで開いていたタブの脇に新規タブをドラッグする手間が省けるわけだ。

f:id:Rockridge:20170212174237p:plain

ちなみに、常にアクティブなタブの右隣に新規タブを表示させるための拡張機能も存在する。Always Rightがそれで、Mozillaの中の人が作者なのでFirefoxの仕様変更がある際にも対応してくれそうだ。

ただ、「常に」ということなので、あるページのリンクを順次新しいタブで開いていく場合、後で開いたものほどアクティブなタブの右隣に来る。好みが分かれるところだろう。

(17/02/12追記)

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版のいずれをインストールするか選択できる

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になると発表された。

関連記事

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

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

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

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

f:id:Rockridge:20170109182106p:plain

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

f:id:Rockridge:20170109183429p:plain

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で動作を確認した。なお、当然ながらアドオン作者の保証外の行為だし、自動アップデートもできない。

f:id:Rockridge:20170109190048p:plain

作者の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の方から以下のとおりコメントを頂いた。


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はクラウドと繋がって、ユーザーにとってのおすすめ情報を取得する。ここでは、ブラウザがユーザーの代理人として、適切に判断して行動するというコンセプトがある。

f:id:Rockridge:20161218180232p:plain

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(関連項目)が表示されている。なお、アクティブでないタブをホバーすると、要約が出るという。

f:id:Rockridge:20161218202934p:plain

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

f:id:Rockridge:20161218205302p:plain

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

f:id:Rockridge:20161218203649p:plain

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

f:id:Rockridge:20161218204131p:plain

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

f:id:Rockridge:20161218204555p:plain

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

f:id:Rockridge:20161218210105p:plain

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

f:id:Rockridge:20161218210306p:plain

次世代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)。