Mozilla Flux

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

ブラウザの「更新の確認は行わない」設定をFirefox 63で削除

Firefox本体のアップデートに関して、現行のFirefox 62には3つの設定がある。オプション画面の〔一般〕セクションをスクロールしていくと見つかるが、1)更新を自動的にインストールする、2)更新の確認は行うが、インストールするかを選択する、3)更新の確認は行わない、となっている。初期設定は1)だが、3)への変更も容易なのが現状だ。Firefox 63ではこの3)の設定を削除し、1)と2)だけとする(Bug 1420514)。app.update.enabledの設定そのものが削除されたため、about:configから復活させることもできない。

Mozillaの狙いは、ユーザーにできるだけ最新バージョンのFirefoxを使ってもらうことにある。Firefox Public Data ReportのUser Activityによれば、リリース直後を除くと、デスクトップ版Firefoxの最新バージョンを利用しているユーザーの割合は75%程度にとどまる。残り25%は理由があってアップデートを留保しているのかもしれないが、そうでない場合も多いはず。たとえば、以前「更新の確認は行わない」設定に変更したまま忘れているといったケースだ。こうしたユーザーは気付かないうちにアップデートから取り残されてしまう。しかし、旧式の拡張機能のサポートが打ち切られ、プラグインもFlashに絞られた今、Firefox本体のアップデートをオフにする積極的な理由を持つのは、主に組織内ユーザーに限られよう。

f:id:Rockridge:20180909220450p:plain
デスクトップ版Firefoxの最新バージョンの利用率。80%を超えることはない。

そこで、Mozillaは前述のとおり本体アップデートの確認すら行わない設定を排除する一方で、従来延長サポート版(ESR)でのみサポートしていた本体アップデート無効のポリシーを、Firefox 62からは通常版にも開放した(Bug 1460082)。組織内ユーザーのニーズに配慮した形だ。ポリシー設定の方法などについては、Mozilla Firefox ESR60でのPolicy Engineによるポリシー設定の方法と設定項目のまとめ - ククログ(2018-05-12)が詳しい。また、UIが日本語化されていないものの、Enterprise Policy Generatorという拡張機能を使えば、グループポリシーの定義ファイル(policies.json)を手軽に作成できる。

Firefoxの最新バージョンはその時点で最も安全であり、Firefox Quantum以降の傾向に照らすと最も高速でもある。Mozillaは最新バージョンをリリース後、できるだけ早くユーザーに提供する取り組みを今後も続けていく。その取り組みの1つが現在開発中のUpdate Agentの導入であり、Firefoxが起動していないときにバックグラウンドで更新のチェックとインストールを実行するというものだ。これによって、いったんFirefoxを起動しないとアップデートが行われない問題が解消される*1。実のところ前述したFirefox 63の仕様変更は、Update Agentがプロファイルを見なくても本体更新が無効かどうかを判別できるようにする取り組みの一環でもあるのだ。アップデートが迅速に行き渡る環境が整った暁には、更新チェックの頻度も現在の12時間おきから短縮されるだろう。

*1:余談だが、Firefoxの起動中に更新のインストールまで終える仕組みは、Windows版ではFirefox 55で、Mac版とLinux版ではFirefox 57で、それぞれ無効化された(Bug 1370576Bug 1397562)。再起動後の動作に支障が生じたためだ。Firefoxが起動していないときにアップデートの適用が可能になれば、起動中にそれを行う必要性は低下する。

Firefoxのアクティブユーザー数やアドオン利用率などが公開

Mozillaは稼働中のFirefoxから技術的な対話データを収集しているが、最近、その膨大なデータを基にFirefox Public Data Reportを公開した。Let’s be Transparent - The Mozilla Blogや上記サイト内の説明によれば、既に2年前から存在するFirefox Hardware Reportを大幅に拡張したもので、3つのセクションに分かれて統計資料が掲載されており、データは毎週更新されるという。今のところデスクトップ版Firefoxのみが対象となっているけれども、そう遠くないうちにモバイル版の資料も加わるようだ。

初期設定では全世界(Worldwide)の資料が表示される。ブラジル、中国、フランス、ドイツ、インド、インドネシア、イタリア、ポーランド、ロシアそして米国の10か国については、個別の資料を見ることもできる。Firefox Public Data Reportは、報道関係者や研究者が参照することはもちろん、Mozillaによるデータの使い方をユーザーに広く知らせる手段ともなることが期待されている。

3つのセクションを順に紹介しよう。1つ目はUser Activityである。デスクトップ版Firefoxの利用者数や日々の利用時間、新規プロファイルの作成率、最新版の利用割合などが掲載されている。注目すべきはFirefoxの月間アクティブユーザー数(MAU)だろう。過去28日間においてアクティブであったデスクトップクライアントの数を計測したもので、本記事執筆時点では、2017年4月1日からの推移がグラフ化されている。ちなみに、2018年9月1日現在のMAUは2億5834万8840クライアントだ。

f:id:Rockridge:20180905001452p:plain
デスクトップ版FirefoxのMAUとその推移

2つ目はUsage Behaviorである。利用者数の多い言語、トラッキング防止機能の常時有効化率(2018年9月1日現在で1.282%)、アドオン利用率などが掲載されている。最後のアドオン利用率は、ユーザーが1つでも(プラグインを除く)アドオンをインストールしているとカウントされるようだ。2018年9月1日現在で34.577%となっているが、Firefox Quantumのリリース前後でさほど変化がないのは興味深い。

f:id:Rockridge:20180905002621p:plain
デスクトップ版Firefoxのアドオン利用率

利用者数の多いアドオンのトップ10も掲載されており、広告ブロック系の拡張機能を利用しているユーザーが多いことがわかる。

f:id:Rockridge:20180905002728p:plain:w400
著名アドオントップ10

3つ目はHardware Across the Webである。従前はこのセクションに該当する項目だけが公開されていた。Firefoxユーザーの利用環境をまとめたもので、GPUモデル、GPUベンダー、ディスプレイ解像度、CPUベンダー、CPUコア数、CPU動作周波率、メモリ容量、利用OS、Flashプラグインの有効化率などが掲載されている。

ややデータが古くて2018年5月27日現在のものではあるが、CPUは圧倒的にIntel製が多く、OSはトップのWindows 7と次点のWindows 10で約8割を占め、Flashはいまだにほぼ6割の環境で有効化されていることがわかる。

f:id:Rockridge:20180905003913p:plain
デスクトップ版Firefoxの利用環境

64bit版と32bit版の利用率の推移も見逃せない。Windows向け64bit版Firefoxのアップデート提供が始まる前、利用割合は64bit版が2割弱、32bit版が8割強という比率になっていた。アップデートの提供開始を機にその比率が急速に逆転したものの、64bit版の伸びが止まり、近時は64bit版が7割、32bit版が3割で安定している。

f:id:Rockridge:20180905004432p:plain
64bit版と32bit版の利用割合

今のところローカライズはされておらず、日本語版Firefox固有のデータが存在しない点もやや残念だが、Firefox Public Data Reportにおいて公開されている各種資料は、今後Firefoxに関する議論や考察を進めるうえで不可欠の材料となるだろう。

Firefox 64本体からフィード購読機能を削除 代替は拡張機能へ

2018年12月11日(米国時間)リリース予定のFirefox 64では、RSS/Atomフィードの購読機能とライブブックマーク機能が本体から削除されるBug 1477667)。その理由は"Removing feed support from Firefox"に詳しいが、要約すると、Firefoxユーザーの99.9%が使用しない機能でフィード自体も廃れつつあるので、デスクトップ版専用の古いコードをメンテナンスしていくコストが釣り合わなくなったというものだ。当初はFirefox 63で削除する話も出ていたが、作業量とタイミングの兼ね合いで見送られた

ライブブックマーク機能の削除に伴い、既存のライブブックマークは自動的にOPMLファイルに変換して保存され、個別の記事はそのURLのブックマークへと置き換えられる(Bug 1477672)。Firefoxが生成したOPMLファイルを別のフィードサービスに読み込ませれば、引き続き購読が可能だ。

また、本体からフィード関連機能が削除されたとはいっても、拡張機能によって代替できなくなったわけではない。Mozilla自身、おすすめの拡張機能をコレクションの形で公開している。たとえばLivemarksを使えばライブブックマーク機能を事実上維持することができるので、今からこちらに乗り換えておくのも手だろう。単にフィードの購読だけならAwesome RSSという拡張機能もある。

RSS/Atomフィードそのものの存在感が低下している中、Mozillaの措置はやむを得ないものだろうが、一抹の寂しさを覚えるのも事実だ。なお、Thunderbirdは独自にフィード購読機能を実装しているため、影響を受けない

Firefox 63に複数タブの選択・操作機能が実装される見込み

Firefox 56まで、複数のタブを選択してそれらをブックマークしたり、選択したタブ以外を閉じたりする操作は、拡張機能を導入することによって実現できていた。だが、Firefox Quantumのリリースに伴い、WebExtensionsベースの拡張機能は本体の操作とシームレスな形では複数タブの選択・操作ができなくなっており、たとえばマルチプルタブハンドラを導入しても、タブバー上のタブを選択することはできず、拡張機能用のパネルを使って擬似的な操作ができるにとどまる。

Firefox 63では、複数タブの選択・操作機能がネイティブに実装され、初期設定で有効化される見通しであり、上記の問題の解消が期待できる(Bug 1474938)。すでにNightlyチャンネルでは有効化済みだ(Bug 1474704)。該当する設定はbrowser.tabs.multiselectで、Bug 1458007がメタバグ、つまり関連する一連のバグの基点となっている。

f:id:Rockridge:20180722213429p:plain
複数タブの選択・操作機能

タブの選択にはShiftキーとCtrl/Cmdキーを用いる。Shiftキーで範囲選択、Ctrl/Cmdキーで個別選択という使い分けだが、範囲選択後にShiftキー+Ctrl/Cmdキーを押しながら選択範囲を拡張することもできる(Bug 1473187)。選択したタブは最上部の色が変わるようになっており、アクティブでないタブ上にカーソルをホバーさせた場合であっても、未選択のタブとは区別が可能だ。

f:id:Rockridge:20180722213646p:plain
タブの選択とカーソルのホバー

本記事執筆時点で実装済みの操作を列挙しておこう。これらの操作は、タブのコンテキストメニューから項目を選択することによって行えるが、今後はショートカットも実装されていく。

  • 選択したタブを閉じる(Bug 1458022
  • 選択外のタブをすべて閉じる(Bug 1472910
  • 選択したタブをブックマーク(Bug 1458067
  • 選択したタブを再読み込み(Bug 1458061
  • 選択したタブをピン留め・選択したタブのピン留めを外す(Bug 1458060
  • (選択した)タブをミュート・タブのミュートを解除(Bug 1458039
  • (選択したタブを)新しいウィンドウへ移動(Bug 1458049

f:id:Rockridge:20180722220025p:plain:w300
タブの複数選択機能の実装により拡張されたコンテキストメニュー

また、近い将来に以下の操作が実装される予定だ。なお、複数タブの選択時に新規タブを開いた場合、選択が解除されるようになる(Bug 1475693)。

  • (選択した)タブを端末へ送信(Bug 1470555
  • 選択したタブをタブバー上のドラッグ&ドロップで移動させる(Bug 1458066
  • 選択したタブをドラッグ&ドロップで別のウィンドウに移動させる(Bug 1458056

複数タブの選択・操作機能がインストールした直後から使えるのは、たとえばChromeに対するアドバンテージとなるだろう。Firefox 56以前の使い勝手を求めるユーザーにとっても朗報と言える。実装される操作も上記で打ち止めというわけではないだろうから、マルチプルタブハンドラが実現していた、「選択したタブをドラッグ&ドロップで既存のブックマークフォルダにまとめてブックマークする」操作も追加される可能性はありそうだ。

(18/08/03追記)
タブバー上のコンテキストメニューの項目が固まってきたようだ。本追記時点の最新スペックは以下のようになっている。

f:id:Rockridge:20180803103228p:plain
タブ選択時のコンテキストメニュー(2018年8月2日時点)

タブの切り替えをスムーズにするTab Warming機能について(Firefox 61以降)

Windows版・Linux版Firefox 61では、Tab Warmingと呼ばれる機能が有効化されている(Bug 1456602*1。タブを切り替える前にいわばウォームアップを済ませておく機能で、ユーザーに見えないところで処理を先取りするため、結果的にタブの切り替え処理が速くなったように感じられる。

タブ切り替えのウォームアップとは具体的に何だろうか。現行のFirefoxはマルチプロセス化されているので、タブを切り替える場合、メインプロセスから切り替え先のタブを司るcontentプロセスに対し、レイヤーツリーを生成するよう指示が出され、その結果がcompositorプロセスに送られて合成(Compositing)の処理が行われる*2。ウォームアップとは、この一連の流れをタブの切り替えが行われる前から開始しておくという意味だ。その後タブの切り替えが実行されなかったときは、レイヤーツリーは捨てられる。

ウォームアップが開始されるタイミングは複数ある。代表的なのは、切り替え先のタブ上にカーソルがホバーしたとき(Bug 1385453)と、タブを閉じるボタン上にカーソルがホバーしたとき(Bug 1430292)である。そのほか、Ctrl+Tabパネルを表示させたとき(Bug 1430153)やマウスの中ボタンの押下を検出したとき(Bug 1472230:ただしFirefox 63から)も対象だ。いずれも手動または自動でタブが切り替わる直前の操作が選ばれている。

Tab Warming機能の性質上、レンダリング処理に時間のかかるWebページほど効果を発揮しやすい。もっとも、タブの切り替えに要する時間は、平均値・中央値ともに減少することが判明しており、特別なケースでなくともユーザーはメリットを享受できる。ちなみに、browser.tabs.remote.warmup.maxTabsの設定値(デフォルトは3)を変更することで、効果範囲の調節も可能だ。

f:id:Rockridge:20180715164711p:plain
タブ切り替え時間の平均値(Mean)と中央値(Median)が低下