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

Mozilla Flux

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

Firefoxのテーマ機能が刷新予定 JavaScript APIを通じて動的な制御も可能に

Fx新着

MozillaはFirefox 57のリリース(2017年11月14日:米国時間)までにテーマ機能を刷新する予定だ。その概略はImproving Themes in Firefox | Mozilla Add-ons Blogで発表されており、窓の杜でも既報ではあるが、今ひとつ具体像が見えず、当ブログでは記事にするのを躊躇していた。だが、最近になってQA/Theming/Testplan - MozillaWikiなどを通じて細部がはっきりしてきたので、ここに紹介しておきたい。

軽量・完全テーマから静的・動的テーマへ

現在、Firefoxは2種類のテーマをサポートしている。軽量テーマ完全テーマがそれだ。軽量テーマは、手軽に作成することができてFirefoxのバージョンアップに伴う互換性の問題も生じないが、Firefoxのユーザーインターフェイス(UI)のうちごく一部しか変更することができない。他方、完全テーマはUIを大きく変更できるが、作者はFirefoxのUIについて内部的な動作を把握することが求められるし、互換性の問題も頻繁に生じる。

こうした違いを反映して、本記事執筆現在、Mozilla Add-ons(AMO)に軽量テーマが42万以上登録されてるのに対し、完全テーマは500しか登録されておらず、しかもFirefoxの最新版と互換性があるのは60程度にすぎないという。同じカテゴリーの中にありながら、軽量テーマと完全テーマは差がありすぎる。そのうえ、これまではFirefoxの外観を制御するJavaScript APIも提供されてこなかった。

そこで、Mozillaは新しいテーマの仕組みを構築し、上記の問題の解決を図ろうとしている。新しいテーマの1つは静的テーマ(static theme)と呼ばれる。静的テーマの中核はJSONマニフェスト*1であり、UI要素に対応したプロパティに色や画像などを指定する。もう1つはWebExtensions APIを用いたもので、テーマ型拡張(themextension)の仮称もあるが、ここでは静的テーマと対比して動的テーマと呼ぶことにする。動的テーマがコントロールできるプロパティは静的テーマと同一だが、JavaScriptを用いて色や画像などをダイナミックに変更できる。動的テーマは実質的にWebExtensionsベースの拡張機能だが、Firefoxのアドオンマネージャでは「テーマ」として扱われる(Bug 1330349)。

MozillaはFirefox 55の時点で、Nightly/Auroraチャンネルにおいてこの新テーマ機能を有効化するとみられる(Bug 1341722)。

軽量テーマは静的テーマに変換 Chrome向けテーマの適用も

従来の完全テーマは、Firefox 57でサポートが廃止される。これは開発版も例外ではなく、Nightlyチャンネルから順に完全テーマは使えなくなっていく。

これに対し軽量テーマは、互換性の問題を気にせず使い続けることができる。ただ、インストール済みのパッケージは自動的に静的テーマへと変換される(Bug 1330338)。Mozillaは静的テーマへの一本化を目指しているのだ。おそらく、ある時期からAMOに軽量テーマを新規登録できないようにして、静的テーマへの移行を促すことだろう。

以上で見てきたように、Firefoxのテーマの仕組みはガラッと変わってしまう。だが、結局のところUI要素に対応したプロパティがどの程度細かなものになるかの問題であるともいえる。きめ細かなプロパティが用意されれば完全テーマに近いことも可能になるが、互換性の維持に責任を持つMozillaとしては、プロパティをあまり増やしたくない。とはいえ、使い勝手が悪ければ誰も新テーマに手を出さなくなってしまう。バランスを取るため、MozillaはFirefoxの開発版ではJSONマニフェスト内でUIのCSSを直接操作できるようにするという。テーマ作者が実例とともに新プロパティの実装を要請すれば、認められるかもしれない。

テーマ機能の刷新により、ユーザーは軽量テーマよりも複雑な内容のテーマを、互換性を気にせず使えるようになる。時間帯や訪問したWebサイトに合わせて変化するテーマも従来より増えそうだ。また、Chrome向けのテーマをそのままFirefoxに適用することも可能とされる。この場合、静的テーマはAMOのデジタル署名が不要なので、作者が自分のWebサイトでChrome向けのテーマを公開し、ユーザーがそれをインストールすればよい。

(17/03/14追記)
Add-ons/Firefox57 - MozillaWikiが改訂され、Nightly/AuroraチャンネルではFirefox 57以降も設定を変更することにより完全テーマを使用できることが明らかとなった。

*1:その構造についてはThe Future of Firefox Theming - Engineering Planを参照。

速度面でFirefox 52は振るわず Quantumによる飛躍に期待

Fx情報

当ブログでは、Firefoxの延長サポート版(ESR)のメジャーアップデート時期を開発の区切りとみて、Web上で実行可能なベンチマークの測定結果を公開している。今回は、Firefox 52のパフォーマンスをFirefox 45と比較してみたい。

この1年の間にマルチプロセス機能(e10s)が初期設定で有効化されるところまできた一方で、64bit版の本格投入は数バージョン先になる。そこで、今回は32bit版のみを対象としつつ、e10sの有無による差をテストすることにした。検証を行った具体的なバージョンを挙げると、32bit版のFirefox 45.7.0(ビルドID:20170118123525)および32bit版のFirefox 52.0 RC2(ビルドID:20170302120751)である。後者はさらにbrowser.tabs.remote.force-enableの設定を追加して値をtrueにしたもの(e10sオン)と、そうでないもの(e10sオフ)に分かれる。

動作環境についてだが、OSは64bit版Windows 10 Professional(Anniversary Update)で、使用したハードウエアは、CPUがIntel Core i7-7500U CPU 2.70GHz、GPUがIntel HD Graphics 620(ドライバのバージョン:21.20.16.4542)、メモリ容量が16.0GB、ストレージがWestern Digital製SATA-IIIのHDDである。GPU描画支援はDirect3D 11、Direct2D 1.1とDirectWriteをバックエンドに使用している。

測定にあたって対象ごとに新規プロファイルを用意し、初期設定からフォントをメイリオに変更したほか、dom.max_script_run_timeの値を0にした(テストが途中で中断されるのを防ぐため)。また、拡張機能はすべて無効化し、プラグインは自動的にインストール・有効化されるものを除きShockwave Flash 24.0 r0だけを常時有効化している。

測定の際には、Turbo Boost機能を無効化し、定格の動作周波数でPCを動作させた。画面サイズは3840×2160で、表示を250%に拡大しており、測定の際のウィンドウは最大化している。なお、各ベンチマークの実行後はFirefoxを終了させて、メモリ上に前のベンチマークが残らないようにした。

最後に、対象となるベンチマークは、前回の記事で用いたものから一部を入れ替えた。

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

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

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

1分間そのまま放置した後、新しいタブを開いてabout:memoryを呼び出し、"Show memory reports"欄のMeasureボタンをクリックし、Main Processのresidentの値を見る。ただし、e10sが有効化された環境では、子プロセスのresident-uniqueの値も合算する*2

そして、「他のタブをすべて閉じる」でYahoo! JAPAN以外のWebページはすべて閉じる。5分間*3そのまま放置した後、再び新しいタブを開き、about:memoryを呼びだしてMain Processのresidentの値を(e10sオンのときは子プロセスのresident-uniqueの値も)見る。Firefoxをいったん終了させ、再起動後に上記10サイトを同じ手順で開いて、throbberが消えるまでの時間を計測する。一連の手順を実行した結果を以下に示す。

Fx 45 ESR Fx 52 STD Fx 52 e10s
読込時間(1回目) 32 秒 27 秒 28 秒
読込時間(2回目) 18 秒 19 秒 21 秒

Fx 45 ESR Fx 52 STD Fx 52 e10s
使用メモリ(10タブ) 590.81 MB 553.88 MB 674.32 MB
使用メモリ(単タブ) 395.66 MB 349.95 MB 418.44 MB

読み込み速度、メモリ使用量ともにFirefox 52の非e10s版が優れている。e10sを有効化すると使用メモリが2割程度増えるが、Firefox 45よりも省メモリ化が進んでいることもあり、思ったほどメモリは喰われなかった。

ストレージ

HTML5 Offline Storage Benchmarkは、オフラインストレージの性能を計測するベンチマークだ。localStorage、WebSQLおよびIndexedDBを対象にできるが、ここではIndexedDBの結果(主に1ミリ秒あたりに処理されたオペレーション数)を掲載する。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Clear 16.25 ms 15.88 ms 15.69 ms
Inject-L 0.38 op/ms 2.62 op/ms 2.39 op/ms
Inject-S 0.82 op/ms 3.19 op/ms 1.33 op/ms
InjectBulk-L 1.37 op/ms 1.86 op/ms 2.23 op/ms
InjectBulk-S 6.02 op/ms 5.94 op/ms 6.05 op/ms
Lookup 8.33 op/ms 5.84 op/ms 5.56 op/ms
Lookup2 11.74 op/ms 9.53 op/ms 7.05 op/ms

Firefox 52になって改善された部分もあれば、悪化した部分もあるが、非e10s版では改善された項目のほうが多い。Snappyライブラリのアップデート(Bug 768074)が影響しているかもしれない。ただ、e10sを有効化すると若干パフォーマンスが落ちるようだ。

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

HTML5 Canvas

CanvasMark 2013 version 1.1は、HTML5ゲームでよく使用される処理(ビットマップ、Canvas描画、αブレンディングなど)に対するレンダリング・パフォーマンスをテストする。

Fx 45 ESR Fx 52 STD Fx 52 e10s
CanvasMark Score 9861 9759 9679

残念ながらFirefox 52で若干スコアが下がっており、e10sが有効になるとさらに下がる。

WebGL

Microsoft Edge TestDrive demosからFishGLをピックアップし、水槽内の魚の数を150匹に設定してテストを実行した。 このテストは、主にWebGLに関する処理性能を測定する。

Fx 45 ESR Fx 52 STD Fx 52 e10s
秒間フレーム数 15 - 17 fps 16 - 17 fps 18 - 19 fps

大きな差はつかないものの、Firefox 52のe10s版がトップに立った。実際にフレームレートの動きを見てもらうとわかるが、安定度でもe10s版が優れている。

次に、Unity WebGL Benchmarks 2015年版での結果を見てみよう。このベンチマークは、Unityの開発したグラフィックスエンジンが一定時間内にどの程度のタスクを処理できるかをテストするものだ。Unity Blogの記事によれば、Unity 5.3がベースになっているらしい。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Overall Score 48634 45417 45684

Firefox 52の成績が悪い。e10sの有効・無効による差は誤差のレベルにとどまる。

最後に、OortOnline.gl v0.2.2でテストを行う。新しく加わったこのベンチマークは、Oort Onlineというオンラインゲームの世界を再現し、典型的なWebGLゲームの描画パフォーマンスを測定するという。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Total Score 4060 4220 3850

Firefox 52の非e10s版が良い結果を収める一方、e10s版はFirefox 45よりもスコアで劣ることになってしまった。

JavaScript/DOM処理

JavaScript

Octane JavaScript Benchmark は、Google製のJavaScriptベンチマークで、バージョン2.0はスループットに加えてレイテンシも重視している。言い換えれば、Webアプリのピーク性能だけでなく、動作のスムーズさも評価の対象となる。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Octane Score 20802 20765 20369
Richards 26169 26325 24817
Deltablue 34110 34038 39658
Crypto 22533 22070 21507
Raytrace 84507 79475 76885
EarleyBoyer 29506 28134 26960
Regexp 2521 3034 3085
Splay 15972 14872 13479
SplayLatency 18632 13668 14429
NavierStokes 21666 22740 23229
pdf.js 10389 8469 9868
Mandreel 17872 17207 15528
MandreelLatency 19550 18062 18261
GB Emulator 40996 45719 36439
CodeLoad 8680 11354 12421
Box2DWeb 25458 30844 27680
zlib 50938 46747 47194
Typescript 18729 20320 17682

Firefox 52 非e10s版の総合スコアはFirefox 45と同程度だが、個別の項目を見ると、上がったり下がったりしているので、たまたま近い結果になっただけのようだ。Mozillaは、CacheIRと呼ばれる仕組みを導入し、 BaselineとIonMonkeyの間でインラインキャッシュ(IC)の処理を共通化しようとしているが、目に見える成果が出るのは、まだ先なのだろう。

他方、e10s版はやや劣る結果となった。個別の項目の傾向は非e10s版と一致しておらず興味深い。

次に、JetStream 1.1を採り上げる。JetStreamはWebKitチームが提供するベンチマーク・スイートで、SunSpider 1.0.2やOctane 2.0からも一部のベンチマークを取り入れ、スループットとレイテンシの双方を計測する。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Score 142.18 ± 3.0406 137.55 ± 2.2040 133.12 ± 2.5195

Firefox 52でスコアが落ち込み、e10sの有効化でさらに下がるという良くないパターンに陥っている。

JavaScript+DOM

Speedometer 1.0は、WebKitチームが提供するベンチマーク・スイートで、DOMオブジェクトの操作に焦点を当て、Webアプリの応答性を測定する。jQueryなど6つのポピュラーなJavaScriptフレームワークを採用し、ユーザーの行動をシミュレートするという。GoogleのV8開発チームが、Octaneよりも実環境に近いスコアが出るとお墨付きを与えたエピソードもある。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Runs / Minute 42.9 ± 0.87 41.7 ± 0.56 41.83 ± 0.36

若干だがFirefox 52が劣る結果となった。e10sの有無による差はほぼなさそうだ。

次に、Esprima: Speed Comparisonsは、各種JavaScriptパーザを用いて、jQuery.Mobile 1.4.2、Angular 1.2.5およびReact 0.13.3という3つのフレームワークを処理させた結果を示すものだ。Esprimaの作者が、自作のパーザの優秀さを示す目的で作成したベンチマークのようだが、ここではEsprima 3.1.3による処理結果のみを掲載する。

Fx 45 ESR Fx 52 STD Fx 52 e10s
処理時間(ミリ秒) 307.1 ms 304.6 ms 301.0 ms

Firefox 52で処理時間が短縮され、e10s有効化でさらに短縮されるという良いパターンだ。ただ、速度向上の程度はそれほど大きくない。

asm.js

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

Fx 45 ESR Fx 52 STD Fx 52 e10s
Score 4929 4856 4975

Firefox 52でスコアがいったん落ち込むが、e10sを有効にすると盛り返すという不思議な結果に。MozillaはWebAssemblyの開発に力を入れており、Firefoxの処理能力はChromeやSafariを凌ぐほどだが、asm.jsの処理に関しては据置きといったところか。

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

MotionMark

新たに加わったMotionMark 1.0は、WebKitチームが提供するベンチマーク・スイートで、複雑なシーンを目標フレームレートでアニメーションさせる能力を測定する。描画処理のパフォーマンスに焦点を当ててはいるものの、重いテストであり、ブラウザの総合力が問われそうだ。画面サイズがMedium(900 x 600)の場合の結果は、以下のようになった。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Score 127.02 ± 3.71% 98.63 ± 4.72% 96.76 ± 1.87%
Multiply 62.48 ± 5.76% 119.84 ± 3.53% 117.41 ± 1.51%
Canvas Arcs 722.68 ± 1.17% 703.10 ± 1.60% 705.42 ± 1.11%
Leaves 159.17 ± 7.78% 150.33 ± 4.47% 135.42 ± 2.15%
Paths 2297.41 ± 1.30% 2291.85 ± 0.82% 2268.73 ± 0.98%
Canvas Lines 1905.91 ± 2.01% 1804.97 ± 0.80% 1760.05 ± 0.96%
Focus 6.81 ± 2.16% 6.66 ± 2.21% 6.79 ± 1.54%
Images 20.57 ± 5.38% 15.30 ± 23.45% 15.82 ± 3.75%
Design 12.43 ± 4.04% 5.66 ± 2.77% 5.57 ± 3.16%
Suits 157.22 ± 7.77% 29.23 ± 1.71% 27.75 ± 2.34%

Firefox 52では一部の項目でスコアが大幅に低下しており、そこが足を引っ張ったため、総合スコアでも大差がついた。e10sが有効だとダメ押しで下がってしまい、厳しい結果である。

Basemark Web

Basemark Web 3.0は、フィンランドのBasemark社が提供する総合ベンチマークで、従来はBrowsermarkの名称が用いられていた。最新のWeb標準と機能を用いて実環境のパフォーマンスを計測できるというのがセールスポイントで、WebGL 2.0を用いたテストもある。以下はConformanceとBatteryの各テストを除いて実行させた結果だ。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Score N/A 237.66 269.57

Firefox 45はWebGL 2.0テストが実行できなかったので、Firefox 52のスコアだけを掲載した。e10sを有効化すると約13%もスコアが上昇しており、今回の一連のベンチマークの中では異色と言える。

RoboHornet

RoboHornet RH-A1は、Benchmark.jsベースの総合ベンチマークで、α版だが完成度は高い(FAQ)。ここでは、標準的なCore Suiteを選んで計測した。

Fx 45 ESR Fx 52 STD Fx 52 e10s
RoboHornet index 99.93 90.87 93.33
Add Rows to Table 3.44 3.43 5.14
Add Columns to Table 1.68 1.97 2.51
Descendant Selector 30.74 26.11 22.10
2D Canvas toDataURL 5.05 5.02 4.95
2D Canvas clearRect 4.97 4.83 4.65
innerHTML Table 4.03 3.32 2.80
Table scrolling 6.11 4.26 4.33
Resize columns 6.15 5.35 5.14
Object Scope Access 3.23 3.28 3.00
ES5 Property Accessors 13.87 13.60 17.83
Argument instantiation 2.79 1.73 1.74
Animated GIFS 0.76 0.66 0.78
offsetHeight triggers reflow 1.26 1.51 1.57
DOM Range API 3.53 3.32 4.17
Write to localStorage 7.36 7.54 7.68
Read from localStorage 4.96 4.96 4.94

Firefox 52で総合スコアが低下した点が目立つ。e10sを有効化すると多少改善されるものの、Descendant Selectorの項目で足を引っ張られてしまい、伸び悩んだ。

WebXPRT 2015

WebXPRT 2015 v1.998.2は、米Principled Technologies社が提供するWebベンチマークである。オフィスワーカー向けWebアプリを念頭に置いたらしきタスク設定となっており、各ベンチマークを繰り返し7回実行することで、判定の精度を高めている。以下の表で、総合スコアは数値が大きいほうがよいのに対し、個別の項目は処理に要する時間(ミリ秒)を示しており、数値が小さい方がよい。

Fx 45 ESR Fx 52 STD Fx 52 e10s
Overall Score 372 ± 11 319 ± 9 328 ± 9
Photo Enhancement 347ms ± 11.04% 342ms ± 7.48% 314ms ± 9.38%
Organize Album 1920ms ± 8.36% 1972ms ± 6.49% 1977ms ± 8.14%
Stock Option Pricing 326ms ± 9.22% 332ms ± 6.61% 323ms ± 5.83%
Local Notes 110ms ± 10.06% 158ms ± 9.29% 161ms ± 8.93%
Sales Graphs 622ms ± 7.63% 701ms ± 7.92% 670ms ± 1.1%
Explore DNA Sequencing 3176ms ± 5.34% 4711ms ± 6% 4663ms ± 7.19%

RoboHornetと同じ傾向が見られる。Explore DNA SequencingやLocal Notesの項目でFirefox 45よりも明らかに処理速度が低下しており、総合スコアにも響いたとみられる。

総合評価

全般的に、Firefox 52の成績は振るわなかった。過去を振り返ると、Firefox 38がほぼ全面的にFirefox 31よりも好成績となっていたのに対し、Firefox 45はスコアが伸びたベンチマークもあれば逆のものもあって、すっきりしない感じになっており、重量級のベンチマークで底力を見せて面目を保っていた。しかし、Firefox 52は、Firefox 45よりも劣る結果となったケースがあまりにも多い。

e10sの有効化に関しても、消費メモリの20%増加と、おそらくプロセス分離のオーバーヘッドがもたらすパフォーマンスの低下が突き付けられた形だ。ただ、Basemark Webのように希望の持てる結果も一部では出ている。いずれにせよ、ベンチマーク結果を眺めていると、e10sを有効化したFirefoxは別のブラウザのような印象を受ける。

この1年間、Mozillaはe10sの段階的導入やWebAssemblyの実装などにリソースを取られすぎたのかもしれない。それとも、性能が頭打ちになりつつあり、従来のような漸進的な手法では改善が見込めないところまで来ているのだろうか。MozillaがQuantumプロジェクトに賭けているのは、そうした状況を打破する面もある、というのは深読みのしすぎか。

次のESRは、Firefox 59がベースとなる。この時点で、Quantum Compositor(GPUプロセス)とQuantum CSS(Stylo)は当然有効化されているだろう。MozillaがQuantum Renderの開発を急ピッチで進めているところからすると、これも有効化までいくかもしれない。また、64bit版が主流になっていることは間違いないし、Flashプラグインは初期設定で無効化されている可能性が高い。旧来型アドオンと訣別するなど代償が大きいだけに、パフォーマンスの飛躍的な向上を期待したい。

*1:対象は今回一部入れ替えた。HTTPS接続の割合も増えている。

*2:Memory Usage of Firefox with e10s Enabled参照

*3:Bug 1188834参照

MozillaがPocketを買収 その狙いとは

Fx戦略

MozillaがFirefoxにPocket(旧Read It Later)を統合すると決めたのは、2015年4月のことだった。それから2年近くを経て、Mozilla CorporationはPocketの開発企業であるRead It Later, Inc(以下RIL社)を買収し、完全子会社化する。この買収に伴い、Firefoxに統合済みの部分だけでなく、Pocketのコードは全面的にオープンソース化される予定だ(Bug 1343006)。ただ、有料版の扱いなど現時点では不明な部分も残る。

Mozillaの発表によれば、今回の買収はPocketが持つコンテンツのレコメンデーション機能を評価したものだという。だが、Pocketを統合した当初の目的は、そうした機能を取り入れることではなかった。MozillaはFirefoxに独自の「あとで読む」機能を実装し、デバイス間で保存リストを共有可能にしようとしていたのだが、それよりもRIL社と提携してPocketを統合するほうが、大きなメリットを得られると判断したのである。RIL社のNate Weiner CEOもインタビューの中で、Mozilla側から統合の話を持ちかけたことを示唆している。

MozillaとRIL社の取引は、レベニューシェア契約を含むものであったと判明しているが、おそらくMozillaにさほどの利益をもたらすものではなかったはずだ。今回の買収にあたり、Pocketに月間アクティブユーザーが1000万人いて、保存されたコンテンツが30億に達することが強調されているけれども、RIL社は総勢25人という小さな会社にすぎない。Mozilla以外の複数社から投資を受けてこの規模なので、米Yahoo!と複数年契約を結んで潤沢な手元資金を有する1000人規模のMozilla Corp.が、RIL社を買収して収入を増やそうとしたとは考えにくい。

Mozillaの意図を読み解く鍵は、Context Graphプロジェクトにある。その全貌はいまだ判明していないが、ユーザーの行動履歴を踏まえておすすめのWebコンテンツを提示する機能を提供しようとするものであることは確かだ。つまり、レコメンデーションである。将来のFirefoxに搭載されるほか、スマートフォン向けアプリとしても提供されることになっている。

ここでいう行動履歴には、Webの閲覧履歴やブックマークだけでなく、位置情報も含まれる。そして、匿名化された多数の行動履歴をあらかじめMozillaが収集・分析しておき、その結果をレコメンデーションに使う点が重要だ。Mozillaは今回の発表の中で、Pocketのコアチームと技術がContext Graphの取り組みを加速させるだろうと述べている。レコメンデーションの精度向上に応用するというわけだが、Pocketが擁する30億もの保存データを使わない理由はないだろう。

ユーザーの行動履歴の中にPocketの保存データを含めるメリットは2つ考えられる。1つはユーザーデータの多角的な収集だ。ユーザーが全く興味のないコンテンツを「あとで読む」ために保存する可能性は低い。ブックマークやWebの閲覧履歴と照らし合わせることで、ある特定のタイプのユーザーがどのようなコンテンツを好むのか、より深く分析できそうだ。もう1つはユーザーデータの広範な収集だ。将来的にアプリ版が大ヒットすればともかく、Firefoxでの利用をメインに考える以上は収集できるデータもFirefoxユーザーのものに限られる。だが、PocketはFirefox以外のブラウザに対応しているし、アプリ版もある。Pocketの保存データを加えることで、Firefoxユーザーを母集団とする偏りを是正できるかもしれない。

Mozillaの真の狙いがPocketの持つ大量のデータにあるのだとすれば、Pocketがブランドも含め現状のまま存続するという今回の発表内容もうなずける。データはWebの現状を的確に反映した最新のものに更新され続けてこそ意味があるわけで、FirefoxがPocketというサービスを囲い込むのは愚かな行為だからだ。ChromeやSafariのユーザーにもどんどんつかってもらい、アプリ版も広く展開していくのが正解なので、おそらくその方向に進むだろう。また、RIL社の完全子会社化も、Pocketに蓄積されたデータを独占するという側面がありそうだ。

もっとも、Pocketが擁するデータをMozillaの別のサービスに使うのであれば、利用規約やプライバシーポリシーの改訂が必要になってくるだろう。Mozillaはこれまでオプトイン方式でユーザー情報を収集する方針を貫いてきており、子会社となったPocketにもこの方針を適用するのが自然なはずだが、その場合レコメンデーションの精度を高めるためにできるだけ多くのデータを収集したいという要請とバッティングする。今後どのような形で折り合いを付けていくのか興味深い。動向に注目したい。

参考記事

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

Fx情報

窓の杜で既報だが、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以降)

Fx情報

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

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

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

f:id:Rockridge:20170212174237p:plain

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

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

(17/02/12追記)

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

Fx情報

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の自動アップデートが開始

Fx新着

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

関連記事