Mozilla Flux

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

Firefox Quantum雑感

"Firefox Quantum"という名称

Mozillaの公式ブログその他を読むとFirefox QuantumはFirefox 57「だけ」の別名に見えるが、実際には数バージョンにわたって使用される名称だ。Photon UIのブラッシュアップはFirefox 59の開発サイクルが終わるまで続くという話があるので、Firefox 60からは元通り数字で呼ばれるんじゃないだろうか。

Firefox 57は、Mozilla Corp.の社運を賭けたといっても過言ではないくらい大きな節目のバージョンになるので、盛り上げるために呼び名を工夫したいのはわかる。が、Quantumプロジェクトの達成度からいうと中途半端な印象だ。今できる高速化を詰め込んだQuantum Flowが成功したので、格好はついたものの、Firefox 57の時点で有効化されたのはQuantum CompositorとQuantum CSSまで。それにQuantum CSSが真価を発揮するのはこれからだ。仮にFirefox 60までQuantumの名前を引っ張るにせよ、Quantum DOMは追加できてもQuantum Renderは間に合うかどうか。

高速化と応答性

いちおうここでもFirefox 57のことをFirefox Quantumと呼ぶことにするが、Firefox Quantumはたしかに速い。Developer EditionやBeta版を試用したユーザーからの評判もいいようだ。ただ、速さは体感的なものでもある。応答性の向上なども感覚に影響を及ぼしているのは間違いない。

Quantum Flowでは速度低下の原因を詳しく分析して、丹念に取り除いた。Firefox 55から効果が出始め、Firefox QuantumではSpeedometer v2ベンチマークにおけるChromeとの差が20%以内にまで縮まった。実環境を反映する度合いが高いとGoogleがお墨付きを与えたベンチマークで、ついにChromeの背中を捉えたのだ。Quantum CSSはGeckoのスタイルシステムからパフォーマンスが落ちないようにしながら、うまくはまった場合は高い効果を発揮する。そのほか、Windows版ではAdvanced Layersと呼ばれるDirect3D 11ベースのcompositorが有効化されている。できるだけ多くのレンダリング処理を1回の描画で済ませることにより、CPU/GPUリソースの無駄遣いをなくすという。

こうした高速化に加えて、Mozillaが従来から取り組んできた成果がFirefox Quantumで全面的に発揮されることになる。たとえばe10sだ。旧式アドオンを排除したことで、e10sが無効になる要素がなくなった。今のe10sはcontentプロセスが4つに増えたe10s-multiである。そして、Quantum Compositorが独立したプロセスで動く中、Async Pan/Zoom(APZ)がキーボードによるスクロールを含めて効いてくる。e10s無効の環境から移行すれば、応答性の違いは顕著だ。1年前にMozillaが、e10sでふつうのWebサイトは400%、複雑なWebサイトは700%応答性が向上すると言い出したときは、さすがに盛りすぎだろうと思ったが、今の状況なら400%アップもありえそうだ。

あと、最近Developer Edition/Beta版をインストールしたユーザーは、ほとんどがスタブインストーラを使っているはずだ。大多数を占めるWindows環境では、これで知らず知らずのうちに64bit化している。Mozillaは64bit版に関し、安定性は高まるが速度は変わらないというスタンスだが、システム要件ぎりぎりまでを念頭に置くからそうなるのであって、多くの環境では若干処理が高速になっていると思う。

新しいUI

Photonの新デザインはUIの隅々にまで及んでいるが、ぱっと目につくのはタブが四角くなったのと、タブバーの背景色の変更、それにメニューパネルが文字中心になったことだろうか。ロケーションバー改めアドレスバーで「…」をクリックすると、ページアクションメニューが表示されるようになっているのだが、ちょっと気付きづらいか。それよりも、ツアー画面のオーバーレイ表示がうるさいかもしれない。これでもスキップがかなりしやすくなったほうだ。開発者たちがNightlyで試行錯誤し始めたころなんか、恒久的にオフにする方法が見つけにくくて、嫌がらせかと思うほどだった。

Mozillaはメニューパネルを一切いじらせない方針だ。項目の追加、削除、並び替えはできない。拡張機能を使っても駄目だ。その代わり、ツールバーのカスタマイズは柔軟にできるようにした。ツールバーに常時置いておくのはあれだが、無効化もしたくない拡張機能のアイコンは、まとめてオーバーフローパネルに放り込んでおけるので便利だ。一方、ダウンロードを始めるとボタンがツールバーに突然出てくる仕様に変わった点は、異論もありそうである。

WebExtensions限定化

旧式アドオンを全部捨てるのは相当な賭けに思えたが、案外Mozillaは勝てるかもしれない。理由は簡単で、Firefox Quantumが速くて軽いからだ。他にあんまりメリットがなくて拡張機能が使えなくなりますでは、ふざけるなという反応になるだろうが、今までのバージョンより圧倒的に速く、軽くなるなら話は別だ。しかも、何でもありだったXULベースの旧式拡張機能に比べると、WebExtensionsベースの拡張機能は重くなりにくいし、今のところWindows版のみだが、まとめて1つの独立したプロセスを割り当てられるので、本体を巻き込んでクラッシュする可能性も大幅に低下している。

Chromeの拡張機能APIを取り込んだことで制約が大きくなった反面、移植は簡単になり、開発者にとっての敷居も下がった。Mozilla Add-ons(AMO)には日々新しい拡張機能が追加されていて、WebExtensionsの割合も増えてきた。現時点でこれだから、Firefox Quantumのリリース前後にはもっと賑わうだろう。しばらくはダイナミックにランキングが入れ替わりそうだ。Chromeの拡張機能を移植したことで、Firefoxユーザーの間で火がつき、Chromeユーザーにも人気が出るといったサクセスストーリーが生まれることを期待したい。

最後に

Chrome一人勝ちの状況の中、勝負はこれからだとばかりにFirefox Quantumが出てきた。Mozillaが自画自賛するように、出来は素晴らしい。その上Quantumプロジェクトはまだ先がある。本命はQuantum Renderで、これにWebAssemblyの最適化を合わせると、ゲームプラットフォームとしてのステージが一段上がるはず。旧式の拡張機能とともに捨てられる技術的負債もあるので、Firefoxの高速化は続く。これでシェアも回復してくれるといいんだが。

f:id:Rockridge:20171001221145j:plain:w400
素晴らしきFirefox

Firefox 56で設定画面を改編 個別設定の検索も可能に

Firefox 56では「オプション」と呼ばれる設定画面(about:preferences)が大幅に変更される。従来8つあったカテゴリーが4つに再編され、これに伴って項目もあちこちに移動しているのだ(Bug 1365133)。2015年5月のFirefox 38で設定画面がタブ化された際も、その基本的な編成は変わることがなかったが、今回は全面的な見直しが行われている。

また、1カテゴリー内の項目数が増えると目当ての設定を探しにくいという問題に対処するため、検索機能も付いた(Bug 1353954)。設定画面を開くと右上のページ内検索ボックスにフォーカスが当たり、ページのスクロールにも検索ボックスは追従する

どのようにカテゴリーがまとめられ、項目が移動したのか、大まかに見ておこう。Firefox 55までの設定画面は、以下のようなカテゴリーの編成と項目のまとまりになっていた。

  • 一般
    • 起動
    • ダウンロード
    • タブグループ
    • パフォーマンス
  • 検索
    • 既定の検索エンジン
    • ワンクリック検索エンジン
  • コンテンツ
    • DRMコンテンツ
    • 通知
    • ポップアップ
    • フォントと配色
    • 言語
  • プログラム
  • プライバシー
    • トラッキング(行動追跡)
    • 履歴
    • ロケーションバー
  • セキュリティ
    • 一般
    • ログイン情報
  • Sync
    • Firefoxアカウント
    • すべての端末を同期する
    • 端末名
  • 詳細
    • 一般
      • アクセシビリティ
      • ブラウズ
    • データの選択
    • ネットワーク
      • 接続
      • キャッシュされたウェブページ
      • オフラインウェブページとユーザーデータ
    • 更新
      • Firefoxの更新
      • 次のソフトウェアを自動的に更新する
    • 証明書
      • 要求

これに対し、Firefox 56では次のように変わっている。

  • 一般
    • 一般
      • 起動
      • タブグループ
    • 言語と外観
      • フォントと配色
      • 言語
    • ファイルとプログラム
      • ダウンロード
      • プログラム
      • デジタル著作権管理(DRM)コンテンツ
    • Firefoxの更新
    • パフォーマンス
    • ブラウズ
    • ネットワークプロキシ
  • 検索
    • 既定の検索エンジン
    • ワンクリック検索エンジン
  • プライバシーとセキュリティ
    • ブラウザープライバシー
      • フォームとパスワード
      • 履歴
      • アドレスバー
      • キャッシュされたウェブページ
      • トラッキング保護
    • 許可設定
    • Firefoxのデータ収集と利用について
    • セキュリティ
      • フィッシング保護
      • 証明書
      • オフラインウェブページとユーザーデータ
  • Firefoxアカウント
    • Firefoxアカウント
    • Sync設定
    • 端末名

2つを比べてみると、〔検索〕と〔Sync〕のカテゴリーは改編後もほぼそのまま残っている。そして、〔プライバシー〕と〔セキュリティ〕が統合されている点もわかりやすい。つまり、今回の改編は、残る4カテゴリーを1つにまとめて並べ替えた点が大きい。

仕様書のリリースノートによれば、2017年6月にバージョンが1.3から2に飛んでおり、この時点でデザインが練り直されている。新デザインは「コンテンツ戦略とユーザーテストの結果」に基づいて決定されたという。筆者の理解だと、Mozillaはユーザーの使いやすさに配慮しつつも、アピールしたい箇所はカテゴリーのまま残したのだ。〔プライバシーとセキュリティ〕と並んで、〔検索〕と〔Firefoxアカウント〕が独立のカテゴリーになっている点は興味深い。将来的に項目を追加する予定があるからこそ、あえてそうなっているように思える。

ちなみに、次のFirefox 57の設定画面では、Photonの新UIに合わせてビジュアル面の改修が実施されるほか、設定の一部も変更される。レスポンシブ化により、表示領域が狭いときはカテゴリーがアイコンのみで表示されるようになる点もポイントだ。

(17/11/04追記)
最近公開されたWhat’s new in Firefox Preferences – Firefox User Experience – Mediumでは、「ユーザーテストの結果」が詳しく紹介されている。記事によると、1.〔プライバシー〕と〔セキュリティ〕はまとめるのがよい、2.〔一般〕は必要だが〔詳細〕と同時にあると混乱を招く、3.アドレスバーの表示内容の制御などに関する設定はプライバシー関連と位置づけたほうが理解されやすい、4.〔Sync〕はカテゴリー名としてわかりづらいという知見が得られたそうだ。改編後の設定画面では、これらの知見が反映されていることがわかる。

Firefox 55で刷新されたインストールプロセス Firefox 57でさらに改善へ

Firefoxを常用していると気付きにくいが、Firefox 55のリリースに伴ってMozillaはユーザーのインストールプロセスを刷新した。ここでいうインストールプロセスとは、ユーザーがデスクトップ版FirefoxのダウンロードページをクリックしてからFirefoxの初回起動が完了するまでを指す。以下の動画は、Windows版Chromeを使ってダウンロードページにアクセスしたという想定で、新プロセスについて解説したものだ。

www.youtube.com

従来のプロセスにおける問題点は、February 2017 Onboarding Test – Verdi@Mozillaに掲載された別の動画で指摘されている。その内容をまとめると、次のようになる。1.ブラウジング開始までに必要なクリック数が多すぎる。2.インストーラやダウンロードページの工夫がインストール体験の向上に結びついていない。3.まっさらな状態でインストールされるため、Firefoxに乗り換えたユーザーが訪れたいWebサイトに直ちにたどり着けない。

問題1を解決するため、Mozillaはインストール完了に必要なクリック数を減らした新インストーラを開発した(Bug 1365998)。ただし、スタブ(軽量)インストーラが対象で、フルインストーラは従来通りである。併せて、ユーザーアカウント制御(UAC)のダイアログで特権の昇格が許可されない場合も、インストーラを終了させず、可能な限りインストールを続行するようにした(Bug 1350974)。また、Firefoxの初回起動時には、既定のブラウザに設定するかどうかを尋ねるプロンプトを表示しないようにした(Bug 1367073)。*1

問題2を解決するため、新インストーラは余分なメッセージを表示しないようになっている。ダウンロードページ側にも工夫が施され、ファーストビューに必要な内容が集約されている。画面が夜の風景なのは、Firefoxの初回起動時に表示されるページ(以下ファーストラン)で太陽が昇る演出になっているためだ。なお、新インストーラのアイコンも、インストール後にFirefoxのアイコンがデスクトップに現れることを意識して、緑の箱の中からFirefoxのアイコンが顔をのぞかせた絵柄に変更されている。

f:id:Rockridge:20170918211848p:plain:w379
ファーストビューに必要な内容を集約

問題2に関連して、ファーストランに表示されるFirefoxアカウント関係のメッセージも改良された。従来はアカウントの作成を促すようになっていたのだが、作成しないとFirefoxを利用できないと誤解するユーザーもいたそうだ。そこで、代わりにログイン画面を出しつつ、アカウントを作成した場合の具体的なメリットを提示するようにした。

他方、問題3の解決は今後に持ち越しとなった。Firefoxのホームタブは検索サービスの提供がメインで、新規タブもMozilla関連のWebサイトしか登録されていない。Firefoxに乗り換えたユーザーが従来のブラウザの履歴やブックマークをインポートしてくれれば、新規タブによく使うページを表示できるのだが、初回起動前に設定移行ウィザードを出す現在のやり方では、効果が薄いことが判明している。ユーザーはとにかくFirefoxを起動させたいので、処理を後回しにしてしまうのだ。そこで、インポートを自動化する計画だったのだが、パフォーマンスに悪影響が出るため採用は見送られた

Mozillaはインストールプロセス刷新を今回実行するまでに、試行錯誤を重ねている。New download and install flow for Firefox 55 – Verdi@Mozillaが事前テストの結果について言及しており、それによると問題1・2を解決した新プロセスは4つの点で成功を収めたという。

  1. インストーラの修正でインストール数が8%増加。
  2. インストーラ以外の修正でFirefoxの初回起動を完了したユーザーが2.4%増加。
  3. 新プロセスに対するユーザーのレーティングは従来と同じ。積極的に評価するユーザーも。
  4. ファーストランの修正でFirefox Syncに2台目のデバイスを接続するユーザーが14.8%増加。

新プロセスのレーティングが変わっていないのに成功と評価する理由が上記記事には記載されていないが、おそらくデメリットが目立っていないという趣旨だろう。新インストーラはオプション設定に移行するボタンや、インストール処理をキャンセルするボタンも省かれている。前者はフルインストーラで代替できるのでよいとしても、後者は誤クリックによってインストールが開始された場合にユーザーはアンインストールを余儀なくされることになる。その意味で、かなり割り切った仕様と言えよう。

Mozillaは、Firefox 57で手動インポートの手順を改善し、積み残された問題3の解決を図る。初期設定でホームタブと新規タブが統一され、利用頻度の高い「トップサイト」や直近の訪問・ブックマーク履歴を基にした「ハイライト」が表示されることを踏まえて、それらのタブに他のブラウザからのインポートを促すメッセージが表示されるようになる(Bug 1361294)。ユーザーが「インポートする」を選んだ場合に設定移行ウィザードが出るのは従来通りだが、移行が完了すると当然ホームタブ・新規タブの内容に反映される。これに対し、ユーザーがインポートを拒否するか、3活動日にわたって何も選択されなかったときは、メッセージは表示されなくなるという仕様だ。なお、この措置に伴ってFirefoxの初回起動時に設定移行ウィザードは表示されなくなる。

以上のほか、Firefox 57のスタブインストーラは、3バージョン以上古いFirefoxのインストールを検出するか、Firefoxがインストールされていない状態で既存のプロファイルを検出した場合、プロファイルのクリーンアップを行う選択肢を有効化した状態で示すようになる(Bug 1369255)。設定が初期化されるうえアドオンも削除されるので、インストール時には注意が必要になるだろう。

f:id:Rockridge:20170918224921p:plainf:id:Rockridge:20170918224941p:plain
左:古いFirefoxを検出した場合 右:既存のプロファイルを検出した場合

*1:プロンプトは2回目の起動時に表示され、表示回数は3回に限定される。Firefox 43に実装された機能だが、今回初めてリリース版で有効化された。

MozillaがWindows向けFirefox 56.0に対し64bit版56.0.1への自動アップデートを提供予定

Windows向けFirefoxの64ビット化は、今、最終段階に差しかかっている。2017年9月28日(米国時間)にFirefox 56.0がリリースされた後、同年10月中には64bit版56.0.1への自動アップデートが提供される(Bug 1274659)。これにより、4GB以上のメモリを搭載した環境ではクラッシュ率が39%も低下するほか、アドレス空間配置のランダム化(ASLR)が強化されてセキュリティも改善される。

2014年9月中旬ころに本格的に開始されたFirefoxの64ビット化は、長らく停滞していたが、2017年3月リリースのFirefox 52でFlash以外のNPAPIプラグインのサポートが廃止されたうえ、Windows XP/Vistaのサポートが延長サポート版(ESR)に移行したことを受けて、一挙に事態が動き始めた。同年4月リリースのFirefox 53では、スタブインストーラから64bit版を選択可能になり(Bug 797208)、同年5月にはWindows上のFirefoxリリース版ユーザーの7%が64bit版を使用するようになった。次いで同年8月リリースのFirefox 55では、スタブインストーラの初期設定が64bit版に変更された(Bug 1340936)。

2017年9月に入って、Firefox Developer Edition 57やFirefox Beta 57では自動アップデートが始まっている。引き続き10月にはリリース版でも自動アップデートが提供されるわけだが、64bit版Windows 7以降を使用し、2048MB超のメモリを搭載している環境であれば対象となる。条件は緩く、Windows上のFirefoxユーザーの大半が64ビット版に移行することになるとみられる。ちなみに、同年7月時点で、Windows上のFirefoxユーザーの約70%が32bit版を使用していたというデータもある。64bit版の自動アップデートの提供が開始されれば、その比率は大きく低下し、遠からず64bit版ユーザーとの逆転現象が起きるだろう。

当面64bit版に移行したくないユーザーはどうすればよいだろうか。Mozillaは2つの方法を用意している。1つは、Firefox/Win64 - MozillaWikiに記載されたレジストリキーを予め設定しておき、アップデートが降ってこないようにするというもの。もう1つは、64bit版Firefox 56.0.1に移行後、32bit版56.0.1をインストールし直すというものだ。Mozillaは、32bit版56.0には自動アップデートを提供するが、32bit版56.0.1にはこれを提供しない。後者の手段は、その差を利用している。*1

64ビット化が完成した後は32bit版のサポート期間が気になるところだが、さすがに現時点で情報はない。64ビット化はChromeが先行しているので、その動向も見ながら決めることになるのだろう。筆者の考えでは、Windows 7の延長サポートが終了する2020年1月14日あたりがそのタイミングにふさわしい。Windows 8.1以降であえて32bit版を選ぶユーザーは、かなりの少数派とみられるからだ。順調にバージョンを重ねていけば、ちょうどそのころFirefox 72がリリースされているはずである。

(17/10/10追記)
Windows向け32bit版「Firefox」の64bit移行が開始へ ~「Firefox」v56.0.1が公開 - 窓の杜で報じられているとおり、64bit版56.0.1へのアップデートが開始された。

*1:なお、MozillaはFirefox ESRに対しては64bit版を強くプッシュすることはなく、ESR 59においても自動アップデートは予定されていない

日本語版Firefoxに初期登録されるフィードリーダーをどうするか(再追記あり)

Firefoxでフィードの購読画面を開くと、ライブブックマークのほかにWebベースのフィードリーダーを選択できる。日本語版Firefox 55の場合、選択肢はLive Dwango Reader(LDR)のみだが、LDRは2017年8月31日にサービスが終了した。これに伴い、Firefoxの初期登録からもLDRは外される予定だ(Bug 1383654)。

だが、このままだと日本語版Firefoxに初期登録されるフィードリーダーがなくなってしまう。そこで、上記バグでは代わりに登録すべきWebベースのフィードリーダーについて議論が交わされている。その内容を紹介する前に、まずは過去の変遷を辿っておきたい。

2011年6月にリリースされたFirefox 5では、日本語版に初期登録されたフィードリーダーは、goo RSSリーダーが外された結果、GoogleリーダーとMy Yahoo!そしてlivedoor Readerの3つに絞られた(Bug 649888)。その後、2013年9月にリリースされたFirefox 24でGoogleリーダーが削除される(Bug 905466)。サービス終了に伴う措置だった。

以降、2016年3月にリリースされたFirefox 45でlivedoor Readerが現在のLDRに変更された(Bug 1244520)程度で、おおむね安定してきたが、2017年8月にリリースされたFirefox 55に至り、サービス終了済みのMy Yahoo!が削除されたのだった(Bug 1355730)。同年11月にリリースされるFirefox 57では、前述のとおりLDRも削除されるだろう。

代わりに登録すべきフィードリーダーとして現在挙がっているのは、FeedlyFeed Watcherである。前者はポピュラーであること、後者は日本語のサービスであることがその理由だ。InoreaderAOL Readerも名前は出ているが、Firefox Nightly 57のコードフリーズが近づく中、それらを積極的に推す声はなく、Feedlyだけにするか、Feed Watcherも加えるかを最終的に決めることになりそうだ。

筆者はFeedlyを推しているためそれでまったく不満はないのだが、Inoreaderを入れてほしいという意見が根強く存在している可能性もある。時間の余裕はあまりないが、意見を表明するなら今のうちだ。これまでは2011年以前から存在していたフィードリーダーをメンテナンスしていただけで、ユーザーの利用状況を反映した新フィードリーダーの追加には手がつけられずにきた。メンテナンスの手間を考えても3つくらいは許容範囲だろう。Feedly、InoreaderとFeed Watcherをすべて初期登録することも考慮されてよいのではないか。

(17/09/11追記)
本記事公開後、上記Bug 1383654では議論が活発化し、Inoreaderを推す声も増えてきた。また、Twitterの「Mozilla Japan コミュニティ」アカウントでも意見を募集し始めた。意見を述べるときは、このアカウントのツイートに返信するのが手軽で確実だろう。

(17/10/28追記)
上記Bug 1383654の修正により、初期登録されるフィードリーダーはFeedly、InoreaderとAOL Readerの3つに決まった。Feed Watcherは、フィード登録用のURLが存在しないため今回は採用が見送られた。一方でAOL Readerが採用されたことに、明確な理由があるわけではない。どうやら登録するフィードリーダーを無理して絞る必要はなかったらしく、現にサービスが続いていて一定数のユーザーがいるから採用しておこうということになったようだ。

(17/11/02追記)
Feed Watcherを開発するカレット株式会社が急遽フィード登録用のURLを追加し、Firefox 57にも採用されることになった(Bug 1413155)。これで初期登録されるフィードリーダーは4つとなった。