Mozilla HacksのWebAssembly連載記事の和訳が開始 続編に期待（追記あり）

Firefox 52で有効化された新機能の1つにWebAssemblyがある。WebAssembly のコンセプト - WebAssembly | MDNの冒頭では、その内容を次のように説明している。

WebAssembly はモダンなウェブブラウザで動作して新たな機能と大幅なパフォーマンス向上を提供する新しい種類のコードです。基本的に直接記述ではなく、C、C++、Rust 等の低水準の言語にとって効果的なコンパイル対象となるように設計されています。

この機能はウェブプラットフォームにとって大きな意味を持ちます — ウェブ上で動作するクライアントアプリで従来は実現できなかった、ネイティブ水準の速度で複数の言語で記述されたコードをウェブ上で動作させる方法を提供します。

それ以上に、その利点を享受するために利用者は WebAssembly のコードをどのように作成するのか知る必要さえ有りません。 WebAssembly モジュールはウェブ (あるいは Node.js) アプリにインポートする事ができ、WebAssembly の機能は JavaScript を経由して他の領域から利用できる状態になります。JavaScript 製フレームワークでは大幅なパフォーマンス改善と開発中の新機能をウェブ開発者が容易に利用できるようにするために WebAssembly を用いることができます。

上記コンセプト記事内には、他にも「WebAssemblyの目標」、「WebAssemblyはどのようにウェブプラットフォームに適合するのか？」、「WebAssemblyをどのようにアプリで用いるか？」といった項目が立てられ、WebAssemblyの概要が的確にまとめられている。ただ、このテーマに関する情報を以前から追いかけてきたならともかく、ふつうのWeb開発者がこの記事を読むと、もう少し背景について掘り下げてほしいと感じるのではないか。

そうした要望に応えるように、2017年2月末、WebAssemblyの概略を紹介する連載記事がMozilla Hacksに掲載された。その内容は充実しており、わかりやすい。だが、6本ある記事はいずれも英語で書かれており、これまで国内でもWebを高速にするアセンブラ技術の今と将来 | マイナビニュースやFirefox, Chrome, SafariがCSS Gridに一斉対応ほか──2017年2月と3月のブラウザ関連ニュース | HTML5Experts.jpで言及されたものの、反響は大きくなかった。

広く読まれるためには、やはり和訳が必要だ。とはいえ、内容が内容だけに、正確な和訳には英語力に加えて相当量の知識が求められる。記事が掲載されてから2か月近くが経過しても動きが見られず、このまま話題に上らなくなってしまうのかと思われた。

そこへ颯爽と登場したのが、WebAssembly の漫画での紹介 | Mozilla Developer Street (modest)である。GWに掲載されたこの記事は、連載の第1弾である"A cartoon intro to WebAssembly"を、T.Ukegawa氏が和訳したもの。連載の中ではいわば導入部分にあたり、WebAssemblyがブラウザで有効化されることによって、2008年にJITコンパイラが登場して以来、久々にJavaScriptのパフォーマンスが大きく向上するフェーズに入るとする。

たぶん今後も連載記事が和訳されていくはずだ。そう信じて、以下、残る5つの記事のさわりだけ紹介しておく。

連載の第2弾は、"A crash course in just-in-time (JIT) compilers"である。WebAssemblyの前史であるJavaScriptインタープリタとJITコンパイラのおさらいから始め、コンパイラによる最適化処理の内容をかいつまんで教えてくれる。その際、stubやbailing outといった概念に触れている点も評価できる。

連載の第3弾となる"A crash course in assembly"でも、まだWebAssembly自体は出てこない。機械語とアセンブラ、さらに中間表現（IR）について、図を交えながら説明している。

連載の第4弾、"Creating and working with WebAssembly modules"に至って、話は一挙に核心に迫る。LLVM（コンパイラ基盤）のIRからWebAssemblyへの変換や、コードの動作、モジュールの構造など扱う内容は多岐にわたり、読み応えがある。

連載の第5弾、"What makes WebAssembly fast?"は、WebAssemblyの速度に焦点を当てる。通常のJavaScriptよりも高速に処理される理由を、Fetching・Parsing・Compiling + optimizing・Reoptimizing・Executing・Garbage collectionの各場面に分けて解説している。第4弾および第5弾のディープな内容は、第3弾までの丁寧な説明があってこそだろう。

連載の最後を飾る第6弾が"Where is WebAssembly now and what’s next?"。WebAssemblyは2017年2月28日にブラウザプレビューの段階を脱し、大手ブラウザはそろって有効化に向けて動いた。今後、パフォーマンスの面ではJavaScriptとの間のファンクションコールを高速化し、WebAssembly自体の読み込み速度や実行速度も改善していく。また、仕様の面ではDOMを直接操作可能にし、並列処理を進め、例外処理のハンドリングを行えるようにする。

（17/05/13追記）
連載第2弾の和訳として、ジャスト・イン・タイム (JIT) コンパイラの短期集中コース | Mozilla Developer Street (modest)が公開されている。

（17/05/22追記）
連載第3弾の和訳として、WebAssembly の短期集中コース | Mozilla Developer Street (modest)が公開されている。

（17/10/02追記）
連載第4弾の和訳として、WebAssembly モジュールの作成と操作 | Mozilla Developer Street (modest)が、連載第5弾の和訳として、WebAssembly を速くするには？ | Mozilla Developer Street (modest)が、それぞれ公開されている。

（17/10/19追記）
連載第6弾の和訳として、WebAssembly は今どこにあり、次に何があるのか | Mozilla Developer Street (modest)が公開され、シリーズが完結した。翻訳者に対し、惜しみない賛辞を送りたい。

マルチプロセス化の完全実施に先行してFirefox 54で多プロセス化を開始

Firefox 48でマルチプロセス機能（e10s）が導入され、Firefox 50から52にかけて、RTL言語ロケールやタッチスクリーン環境でも順次e10sが有効化されるようになった。また、拡張機能をインストールしている環境でも、WebExtensionsベースのもの（Firefox 49以降）やe10s互換性のあるもの（Firefox 50以降）については、有効化を妨げないようになった。若干予想外な出来事として、Firefox 51で追加された拡張機能のホワイトリストがその後撤回され、Windows版でアクセシビリティツールが動作している場合はFirefox 55まで有効化が延期されるといったことがあったものの、2017年4月3日（米国時間）時点で、リリース版ユーザーの52.82％がe10s有効化に至っている。

こうした状況を踏まえ、MozillaはFirefoxの多プロセス化を実行に移す。その中心はcontentプロセスの複数化（e10s-multi）だ。最近までFirefox 55がそのターゲットとされていたが、Firefox 54に前倒しされる可能性が高くなってきた。

2017年1月下旬にFirefox Nightly 54で2つのcontentプロセスが（Bug 1303113）、3月中旬にFirefox Nightly 55で4つのcontentプロセスが（Bug 1336398）、それぞれ有効化され、4月上旬にはFirefox Aurora 54でも4つのcontentプロセスが有効化された（Bug 1304546）。この流れはロードマップどおりであり、あとはBeta版でのテストを経るのみとなっている。

Mozillaがe10s-multiにおいてcontentプロセスを4つまで増やす背景には、省メモリ化の進歩がある。Are they slim yet, round 2 – Eric Rahmによれば、2016年2月から1年余りの間にデスクトップ版の各プラットフォームで、多プロセス化した場合の消費メモリが顕著に低下したという。1年前にcontentプロセス×1で消費したメモリ量は、現在のWindows版だとcontentプロセス×2に相当し、macOS版に至ってはcontentプロセス×4に相当する。Chromeとの比較でも優位に立っていて、特にWindows版/Linux版では差が大きい。

e10s-multi以外の多プロセス化については、mozilla.dev.platformのAll the processesスレッドにまとめられている。既にWindows版ではGPUプロセスの導入が始まっており、今後はWebExtensionsベースの拡張機能やPDFium/Pepper API版Flashのほか、Service workerも独立したプロセスの対象となっていく。

以上のように多プロセス化が展開される一方、その基礎となるe10s有効化は完全実施の時期がFirefox 57まで延期された。当初はFirefox 53で実現する予定だったが、拡張機能のe10s対応がMozillaの想定していた以上に進まなかった。

Firefox 56まで、拡張機能をインストールしている環境では、すべてがWebExtensionsベースまたはe10s互換性ありになっていない限り、e10sは有効にならない。そのため、古い拡張機能を使い続けている場合、Firefox 57にアップデートした時点でその拡張機能が動作しなくなるばかりか、本体がいきなりe10s-multiの状態になる。一部では混乱もありそうだ。

（17/06/13追記）
Firefox 54正式版のリリースに伴いcontentプロセスの複数化（e10s-multi）が有効になるのは、「e10sが有効かつアドオンをインストールしていないユーザー」の80％にとどまる（Bug 1367244）。Mozillaは、次のFirefox 55では「e10sが有効かつ従来型アドオンをインストールしていないユーザー」全員を対象にe10s-multiを有効化しようとしている。

Firefox Developer Editionは早期Beta版として存続 未署名のアドオンも引き続き利用可能

速報：Firefox 55でDeveloper Editionの廃止が決定 - Mozilla Fluxを公開してから3週間が過ぎた。この間、Mozillaのリリースマネージメントチームが"Dawn project or the end of Aurora"（以下「公式アナウンス」）でAuroraチャンネルの廃止を正式に発表した。ところが、実は公式アナウンスの後も計画が変更されている。本記事執筆時点の最新情報をお伝えしよう。

Auroraチャンネル廃止の影響範囲とスケジュール

Auroraチャンネルの廃止は、Firefoxデスクトップ版のみならずAndroid版も対象となっている。だが、Google Playはアプリの作成者がユーザーを別のアプリに引き継がせることを認めていない。そこで、MozillaはFirefox Aurora for DevelopersアプリをNightlyビルドのアプリに置き換える予定だ。

また、ThunderbirdやSeaMonkeyでもFirefoxのAuroraチャンネル廃止と同様の措置が執られる。これによりEarlybirdも終了となる。

Firefoxの新しいスケジュール（米国時間。以下同じ）は以下の公式画像が見やすい。ただ、RapidRelease/Calendar - MozillaWikiによるとFirefox 56のリリース時期は2017年9月26日となっている。公式画像は古いスケジュールのまま作ってしまったようだ。

Firefox Developer EditionはBeta版の派生ビルドへ移行

Mozillaは、Auroraチャンネルの廃止後もFirefox Developer Editionの提供を続ける。これまでと違うのは、Firefox Beta版をベースにする点だ。従来通り独立したブランドとしてMozillaのWebサイトで公開されるほか、従来のユーザーにはBeta版をベースにした新Developer Editionが自動アップデートで提供される（Bug 1353825）。この際、Developer Edition用のプロファイルは維持され、設定やテーマだけでなくショートカットも変更されることはない。

新Developer Editionは、通常Beta版と同様に概ね週2回のアップデート間隔になる。もっとも、アップデートの設定上は「早期Beta」と呼ばれて区別され、NightlyからBetaへの移行時、まずは新Developer Editionのユーザーが対象になるという差がある。ここで問題が見つかった機能は無効化されて、通常Beta版ユーザーに提供される。おそらく、他にも新機能を実験的に有効化するなど、新Developer Editionだけに適用される措置があるだろう。

公式アナウンスが出たのは2017年4月17日だが、この時点で新Developer Editionは通常Beta版のrepackつまりカスタマイズ版になるはずだった。Mozillaは提携企業がFirefoxのカスタマイズ版を作成できるようにしているが、この機能を利用していわば公式カスタマイズ版となる新Developer Editionを作成し、作業に要する時間やコストを抑えようとしたのだ。

しかし、この方法ではmacOS版において問題が発生することがわかった。Developer Editionのアイコンやアプリケーション名が変更されてしまうのだ。検討の結果、Auroraチャンネルの廃止によって浮いたリソースを流用し、Betaチャンネルのコードを基にDeveloper Editionビルドが作成されることになった（4月21日決定）。この方法だと自動化テストも必要になるため、カスタマイズ版よりも作業時間やコストは大幅に増える。

ユーザーにとって大きいのは、Beta版のカスタマイズではなく独自ビルドとなったことで、従来のDeveloper Editionと同様に、Mozilla Add-ons（AMO）のデジタル署名が付いていないアドオンを引き続き利用できるという部分だろう。副作用としてリリース候補版相当のアップデートが受け取れなくなるが、早期Beta版の位置付けからすればほとんど問題にならない。

ローカライズはNightlyチャンネルでの作業がメインに

Auroraチャンネルが廃止されると、Firefoxのローカライズ作業は必然的にNightlyチャンネルがその中心となる。では、Nightlyからリリースまでの期間が6～8週間も短縮されることに、どう対処していくのか。

1つの回答が、cross-channelの導入である。すなわち、Nightly用・Beta版用・リリース版用に分かれているローカライズ向けリポジトリを一本化する。そうすることで作業の重複を省き、新規投入・修正される文字列の翻訳に集中することができるわけだ。Mozilla Corp.でローカライズ担当エンジニアを務めるFrancesco Lodolo氏によれば、Auroraチャンネルの廃止時期が予期せず前倒しになったため、cross-channelを直ちに導入することはできないものの、Nightly 56への切り替えには何とか間に合わせるという。

もう1つの回答が、2017年後半に予定されるL20nの導入である。L20nはローカライズ・国際化に関する新しいフレームワークであり、これがFirefoxに実装されると、FTL構文を用いることで翻訳担当者の作業が容易になるだけでなく、Firefox本体のリリースから独立したローカライズ部分のアップデート（「翻訳のライブアップデート」と呼ばれる）も可能になる。要するに、リリース直前に文字列の修正などがあって翻訳作業が間に合わない場合でも、後から翻訳されたものに差し替えられるようになるのだ。

トップダウンの決定？

Auroraチャンネルの廃止が判明してから3週間の動きを見ていると、Mozillaの準備不足が目につく。過去に類似の計画が実現できずに終わっているにもかかわらず、リリースマネージメントの担当者らは実施方法の細部を詰めていなかったし、実施時期についてローカライズ担当者らとの調整も行っていなかった。しかも、Auroraチャンネル廃止の狙いであったはずのビルド作業・テストの省力化は、Developer Editionビルドの作成を決めた時点で実現できなくなったわけだが、そのことで揉めた様子もない。これらのことから、筆者は今回の廃止がトップダウンによるものではないかと疑っている。

Nightlyからリリースまでの期間が短くなれば、ユーザーは最新の機能を従来よりも早く手元で使うことができる。同じことを開発者サイドから眺めてみると、QuantumプロジェクトのようにFirefox 57で一定の成果を示すといった形で締切りが決まっている場合、より締切りに近い時期まで開発作業を続けることが可能になる。ユーザーの得になるうえ6～8週間の開発期間が捻出できるとなれば、Firefox開発の責任者としては多少の無理を押してでも実行に移そうとするのではないか。外部からは知るよしもないが、Senior Vice President, FirefoxのMark Mayo氏か、Vice President, Product, FirefoxのNick Nguyen氏のコメントを聞いてみたいものだ。

（17/06/13追記）
米国時間の5月26日ころに Firefox 54 Beta 11ベースのDeveloper Editionのインストーラが公開され、6月1日には既存のDeveloper Editionユーザーに対しBeta 12ベースのアップデートの配信が開始された。

Windows版Firefox 53でQuantumプロジェクトの成果が初披露

Firefox 53では一部の環境においてQuantum Compositorが初期設定で有効化される（Bug 1307578）。ここでいうcompositorは、Webページ内のいろいろな要素が複数のレイヤーにレンダリングされているのを1つにまとめ、スクリーンに送り出すシステムのことである。Firefoxのマルチプロセス化（e10s）に伴い、compositorはchromeプロセス内の独立したスレッドとなっているが、そのスレッドをプロセスとして独立させたものがQuantum Compositorだ。旧名をGPUプロセスといい、現在でもその名称がよく使われる。

当然ながらQuantum Compositorは、e10sが有効化されていなければ動作しない。また、Windows 8以降か、Windows 7であればプラットフォーム更新プログラムを適用済みである必要がある（Bug 1297822）。DXGI 1.2以降のAPIを使用するためだ。加えて、PCのグラフィックスドライバがMozillaにより不適格と判断された場合もアウトだ。Mozillaの推計では、Firefoxのリリース版ユーザーのおよそ25％がこれらの条件を満たす環境に該当するという。無事有効化された場合、タスクマネージャーのバックグラウンドプロセスの欄にfirefox.exeの項目が1つ増える（Bug 1309890）。

Firefox Beta版におけるQuantum Compositorのテスト結果をまとめた記事が、"GPU Process in Beta 53"である。それによると、Quantum Compositorを有効化した場合、ドライバ関連のクラッシュが17％低下、Direct3D関連のクラッシュが22％低下、動画再生のハードウェアアクセラレーション関連のクラッシュが11％低下とめざましい効果が上がったという。しかも、代償となるような本体動作の不安定化は特に生じておらず、ほぼストレートにグラフィックス関連の処理が安定することになる。

Quantumプロジェクトの成果第1弾としては、なかなかのものだろう。また、将来的にQuantum Renderが有効化されるのも、少なくとも当初はQuantum Compositorが有効化された環境に限られることが決まっており、地味ながらその果たす役割は決して小さくない。

Firefox 53でパーミッション通知のデザインが変更

Firefox 41以降、認証や通信の暗号化に関する情報は、トラッキング防止やパーミッションに関する情報とともに、コントロールセンターと呼ばれるパネルに集約されている。Firefox 53ではこのパネルのパーミッション通知に関する部分が改善され、ダイアログも新しくなる（Bug 1282768）。

改善のコンセプトやデザインを説明した記事が、"Feeling safer online with Firefox"である。記事によると従来のデザインは、プロンプトをうっかり消してしまいやすい、個別のサイトにおけるパーミッションの管理がたいへん、スクリーン共有の際のアクセス権限付与が面倒といった問題があったという。Mozillaの開発者たちは、コントロールセンターの仕組みを継承しつつ、こうした問題に対処することにした。

まず、パネルのパーミッションに関する表示をシンプルにした。過去または一時的に機器等の利用が許可された場合はアイコンを赤く表示し、ドロップダウンメニューを廃止して許可・不許可の切り替えを1クリックで行えるようにした。

Webサイト側が機器等の利用許可を求めてきた場合も、ダイアログに2つのボタンが色違いで示されるので、どこを押せば許可・不許可になるのか迷わなくて済む。しかも、このダイアログはいったん別のタブに切り替えて戻ってきた場合も消えずに残る。

ちなみに、新しいダイアログはログイン情報の保存の場面にも用いられる。このとき、ドロップダウンメニューから別のボタンを呼び出すことが可能だ。

また、スクリーン共有の際のアクセス権限付与についても、サイトをホワイトリストに登録する作業が不要になり、共有する内容をダイアログ上の選択肢から指定できるようになった。

それほど目立つ変更ではないが、入念な検討を重ねた末に導入されているだけに、使い勝手は良好だ。また、ダイアログの新デザインは、アドオンをインストールする場面などで繰り返し目にすることになるだろう。今後は、Firefox 55で本体のアップデートに関しこのダイアログが用いられる（Bug 893505）など、別の箇所にも応用されていくようである。