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）など、別の箇所にも応用されていくようである。

ServoのWindows版Nightlyが公開 ギーク向けのプレα版

待望のWindows版

窓の杜で既報だが、ServoのWindows版Nightlyが公開されている。ダウンロードページからMSI形式のインストーラを取得することができ、Windows 7以降で動作する。

Servoはモダンかつ高パフォーマンスを謳うブラウザエンジンであり、MozillaはServoの開発過程で得られた成果をFirefoxの基盤となるGeckoに採り入れていく予定だ。その意味で重要なソフトウェアなのだが、Windows版Nightlyの提供は遅れに遅れた。

macOS版とLinux（64bit）版が公開されたのは、2016年6月30日（米国時間。以下同じ）のこと。このときWindows版は近日公開とされ、7月20日が当初の目標であり、現に7月28日にはダウンロード用のリンクもGitHubで公開された。だが、そこからが長かった。Blockerバグが潰されては新しく登録されることが繰り返された。2017年に入っても状況は変わらず、3月14日にはMozilla Corp.でSenior Research Engineerを務めるJack Moffitt氏が次のようにコメントしていた。

We'll be shipping core components of Servo in Firefox releases later this year, focusing on the Windows platform. However, Servo by itself is not web compatible enough yet that you can use it as a replacement for Chrome or Firefox, and so at this stage we have focused on core functionality that is platform agnostic rather than platform specific functionality. What platform specific functionality we do have now is a direct result of the individuals working on Servo making it usable for themselves during development, not the result of targeting deployment for specific OSes.

我々はServoのコアコンポーネントを今年後半にFirefoxのリリース版に投入する予定で、Windowsプラットフォームがその対象となる。しかし、Servoそれ自体は今のところWeb互換性が十分でなく、ChromeやFirefoxの代わりとしては使えない。そのため、現段階で我々はプラットフォーム特有の機能ではなく、プラットフォームに依存しないコア機能に注力している。今あるプラットフォーム特有の機能は、Servoに取り組んでいる個々人が開発の過程で使えるようにしただけで、特定のOSへの展開を狙った結果ではない。

ユーザー規模の大きいWindows版を早く公開すべきとの声もあったが、開発者たちはあくまでも慎重で、4月13日にようやく正式発表（Windows nightly builds now available | Servo Blog）に至った。なお、4月6日にはMozilla Hacksの記事において自分でWindows版Servoをビルドする方法が紹介されている。

日常的な利用には適さず

Nightlyをインストール後、Servo Tech Demoを起動すると、フロントエンドであるBrowser.htmlが表示される。Firefoxの新規タブページのように、所定のページへのリンクとなるタイルが並べられ、上部には検索バーもある。検索バーのさらに上に見える「＜」の記号は、戻るボタンだ。

画面右上にはタブを追加する「＋」ボタンがあり、その脇のメニューボタンをクリックすると、タブの切り替え画面に遷移する。この切り替え画面では、既存のタブを閉じることができるほか、ピン留めのボタンをクリックして画面右端にタブバーを固定することも可能だ。

ミニマリスト的なUIはロケーションバーも排除している。Firefoxとは勝手が違うものの、Microsoft Edgeと同じなのでさほど違和感はないはずだ。デフォルトの検索エンジンはDuckDuckGoに設定されている。一応入力補完機能は備わっているが、処理は遅くあまり使いものにならない。日本語の直接入力にも対応していない。

英語を用いた静的なWebページは大体崩れずに表示できるようだ。表示速度はまちまちで、中には高速に表示されるコンテンツもあるが、概ねもっさりとした印象を受ける。

他方、マルチバイト対応は限定されており、日本語が上手く表示できるケースはまれだ。

終了ボタンがないので、ウィンドウを閉じて終わらせる。ただ、正常に終了しないことも多く、タスクマネージャからバックグラウンドプロセスが残っていないか、毎回確認する必要があるだろう。また、ハングもしょっちゅう起きる。エラーメッセージが出てきた際、UIがハングしていたためGitHub上のServoのページへリンクするボタンが押せないことがあった。

ブックマーク機能や履歴の表示機能も実装されておらず、初期設定にないWebページは毎回手入力で呼び出すことになる。本体のみでアップデートを完結させることもできず、更新にはインストーラが必須だ。

以上のとおり、プレα版なので仕方ないが、機能の面でも安定性の面でも完全にギーク向けとなっている。せめてWeb上の各種ベンチマークを完走させられるようになれば、もう少しユーザーを呼び込めると思うのだが、当分先になりそうである。

速報：Firefox 55でDeveloper Editionの廃止が決定（追記あり）

Auroraチャンネルの廃止

4月1日だがエイプリルフールのウソ記事ではない。Mozilla Corp.でFirefox release management leadを務めるSylvestre Ledru氏は、米国時間の2017年3月31日、Firefox 54を最後にAuroraチャンネル（Developer Edition）を廃止する旨を明らかにした（Project Dawn or the end of Aurora）。Mozillaは2月のFOSDEM 2017で、Nightlyの品質が十分ならAuroraは不要になるとアピールしていたが、筆者の予想を超えた早さで実現する運びとなった。

Auroraチャンネルの廃止に伴い、そのままだと製品版のリリースが前倒しになるため、Firefox Nightly 55の開発サイクルを通常の2サイクル分とすることで調整を図る。具体的には、2017年6月12日までNightly 55が続いて、翌13日にFirefox 55のBeta 1がリリースされることになる。その後は通常の6～8週間の開発サイクルで、NightlyからBetaへと移行する。

もっとも、MozillaはBeta版が不安定になってよいと考えているわけではなく、Beta版に載せる品質に達していない機能は移行時に無効化される。また、Beta 1の時点で新機能をユーザーに対し段階的にロールアウトし、その結果を見ながらBetaチャンネル内で有効化するかどうかを最終的に決める場合もあるという。

これまでFirefox Developer Editionを使用していた開発者やヘビーユーザーは、新機能を取るならNightlyを、安定性を取るならBeta版をそれぞれ選択することになるだろう。Firefox 53以降、Developer Edition専用テーマに近いCompact Darkテーマが他のチャンネルでも使える（Bug 1314091）ようになっているため、移行後の外観が変わることもない。

なお、Auroraチャンネルの廃止はデスクトップ版とAndroid版に共通の措置だが、Android版AuroraユーザーをスムーズにNightlyに移行させる方法については検討中とされている。

廃止の背景事情

Auroraチャンネルの導入は2011年に遡る。Firefoxはバージョン5から高速リリースサイクルに移行し、当初"dev"、次いで"experimental"と呼ばれた開発チャンネルは、2011年4月までに現在の名称で呼ばれるようになった。その後、Firefoxのリリース10周年を迎えた2014年11月、Firefox Developer Editionとして開発者向けにアピールされることになった。

だが、Auroraチャンネルに対しては比較的早い段階からその存在に疑問符が付けられていた。たとえば、2013年10月に提案された「連結列車モデル」では、NightlyとBetaの期間を長く取る代わりに、Auroraの期間を短縮する開発サイクルになっていた。その背景事情として、Auroraのユーザー数が伸びなかったことが大きい。もともとNightlyユーザーの10倍程度になることが期待されていたのだが、Developer Editionとして宣伝を初めて優に2年以上が過ぎた現在でさえ、デスクトップ版Auroraの常用ユーザー数はNightlyの3～4倍にとどまっている。

Developer Editionの登場と同時期、2014年11月には、Mozilla Corp.でPrincipal Engineerを務めるL. David Baron氏が、事実上AuroraチャンネルとBetaチャンネルを統合し、Nightlyからリリースまでの間隔を短縮する旨の私案を公表している。ChromeがCanary、Beta、Releaseの3チャンネルになっていることを意識したとみられるが、この私案と今回の決定の類似性は明らかだろう。

Auroraチャンネルが廃止されれば、従来よりも新機能が迅速に一般ユーザーの手元に届く。チャンネル1つ分のビルド作業やテストが不要になるだけでなく、400～600ものパッチを追加投入（uplift）するコストも省ける。これらに釣り合うだけの品質向上というメリットがあればよいのだが、MozillaがFirefox 46から50までの後退バグを調査したところ、Nightlyサイクル中に見過ごされてそのままリリースまで行ってしまったケースが多いという。結局、Auroraチャンネルはこれを維持するだけの価値を示すことができず、今回の廃止決定に至った。

ユーザー数が相対的に多いデスクトップ版でもAuroraチャンネルがNightlyチャンネルに切り替わるのか、ローカライズにかける時間が足りなくなるという上記私案に対し示された懸念は解決したのかなど、現時点では不明確な点も残る。判明し次第、本記事に追記したい。

（17/04/22追記）
追記の範囲ではカバーできないほど新情報が多かったので、新しい記事を書いた。続報はFirefox Developer Editionは早期Beta版として存続 未署名のアドオンも引き続き利用可能 - Mozilla Fluxをご覧ください。

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

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を参照。