Mozilla Flux

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

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がリリースされているはずである。

*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 コミュニティ」アカウントでも意見を募集し始めた。意見を述べるときは、このアカウントのツイートに返信するのが手軽で確実だろう。

FirefoxのFlash無効化は2019年4月ころの見通し

Firefox 55がリリースされてしばらく経つが、Adobe Flashプラグインに関し、本記事執筆時点で5%のユーザーが「実行時に確認する」の初期設定になっている(Bug 1372237参照)。Flashコンテンツの再生・実行時にユーザーのクリックまたはタップが要求されることから、クリック・トゥ・プレイ(CtP)と呼ばれるのがこの設定だ。

対象ユーザーの範囲は、いったん25%に引き上げられた後で100%に引き上げられる形で、段階的に広がっていく。本来なら既に25%のステージにいるはずなのだが、展開が遅れており、この様子だとCtPの100%達成はFirefox 56のリリースを待つことになるかもしれない。

今回のCtP化は、Mozillaの脱Flashの動きの一環だ。Adobe自身が2020年末をもってFlashプレイヤーの更新と配布を終了すると発表しており、MozillaもESR(延長サポート版)を除き2019年中には大半のユーザーを対象に初期設定でFlashを無効化するとアナウンスしている。とはいえ、Flashを利用するWebサイトはまだまだ多い。Mozillaは、焦らずゆっくりと、しかし着実に脱Flashに向けた歩みを進めていく。

Plugin Roadmap for Firefox - Plugins | MDNが公表されているロードマップだ。それによると、MozillaはFirefox 55の時点で、FlashのCtP化のほかにドメイン単位のブロックを行っている。これは、プラグインの有効・無効をドメイン単位でコントロールするホワイトリスト/ブラックリストの仕組み*1を前提に、他のWebサイトに埋め込まれたWebサイトが起動させるプラグインや、有名なWebサイトが不必要に用いるプラグインをブロックするというもの。アドオンマネージャの〔プラグイン〕からShockwave Flashの詳細ページを開くと、「危険で出しゃばりなFlashコンテンツをブロック」にチェックが入っており、この機能が有効化されていることがわかる(Bug 1348089参照)。*2

次のFirefox 56では、Android版においてプラグインのサポートが廃止される。また、プラグインの初期化処理の非同期化に関するコードも削除されるAsynchronous Plugin Initialization: Requiem - Aaron Klotz at Mozillaで説明されているとおり、この機能は一度もリリース版に投入されることのないままお蔵入りとなった。

2018年の後半になると、FirefoxはFlashの設定を記憶しなくなる。現在の仕様では、FlashがCtP化されていても、ユーザーはFlashを「常に許可する」ドメインを指定できるが、ロードマップの記載は、この仕様を廃止することを意味する。もっとも、ユーザーがアドオンマネージャなどからFlashを「常に有効化する」ことができると、この措置は骨抜きになってしまう。おそらく2018年の前半のうちに、包括的な常時有効化の設定は排除されるだろう。

2019年の初めころから、FirefoxはFlashの利用を続けるWebサイトで警告を表示するようになる。Flashが初期設定で無効化されるのはその数か月後だ。ユーザーは設定を変更して再度有効化できるが、その対象は一部のWebサイトに限定されるという。ホワイトリストに掲載されたドメイン以外では、Flashの有効化を認めないということだろう。従前からのリリーススケジュールを考慮すると、Flash無効化の時期は2019年4月ころになるとみられる。

2020年の初めころ、Firefoxの通常版ではついにFlashのサポートが全面的に廃止される。他方、ESRでは2020年末までFlashのサポートが続く。筆者はかつて、FirefoxにおけるFlashのサポートが完全に廃止されるのは、通常版で2018年半ばから後半にかけて、ESRで2019年第1四半期以降になると予想したのだが、実際のロードマップはより漸進的であった。

なお、MozillaはNPAPI版のサポートを続けることが負担であるとして、FirefoxのFlashプラグインをPPAPI版に切り替える計画を持っていた(Bug 1264552)のだが、PPAPI自体の存続に疑問があるらしく、計画の先行きが不透明になっている

(17/09/11追記)
PPAPI版FlashプラグインをFirefoxに標準搭載する計画は中止された。Mozillaは今後も上記のロードマップで現行のNPAPI版Flashをサポートし続けるほかない。

そうなると懸念されるのは、Firefoxの安定性への影響だ。Firefox 57で旧式のアドオンのサポートを廃止した後、Flashを原因とするクラッシュがFirefoxの安定性にとってネックになってくる可能性がある。

*1:Bug 1307604およびBug 1345611

*2:そのほか、Firefox 55ではFlashコンテンツの読み込みがHTTP/HTTPS接続からに制限され(Bug 1335475)、情報バーにプラグイン関係の情報が表示されることもなくなっている(Bug 1377036)。

「スクショ」を通じたページの共有を促すFirefox Screenshots

Firefox 55にはシステムアドオンの形式で新しいスクリーンショット機能が提供されており、その名をFirefox Screenshotsという。窓の杜の記事「『Firefox 55』で追加されたスクリーンショット機能が便利! ~有効化する方法を紹介」で取り上げられていたので、ご存じの方も多いだろう。この機能は段階的に有効化されるユーザーが増加する仕組みとなっていて、米国時間の2017年8月21日から23日までが1%、24日から29日までが10%、30日が100%というスケジュールで増えていく。つまり、今月末には全ユーザーを対象として、初期設定でFirefox Screenshotsが有効化される。

(17/09/07追記)
Firefox Screenshotsの全面的な有効化はFirefox 56に持ち越された。最新の計画によると、有効化されるユーザーの割合は、9月6日に12.5%、9月13日に25%、9月20日に50%となる。

f:id:Rockridge:20170828225302p:plain

以前からFirefoxの開発ツールにはWebページ全体のスクリーンショットを撮影する機能が含まれてきた。また、スクリーンショットを撮れるようにする拡張機能は定番の1つなので、Add-ons for Firefoxを探せば好みのものを見つけるのは難しくない。それでもあえて今、Mozillaがスクリーンショット機能、しかもオンラインを前提にし、選択範囲の撮影に特化したものを本体に追加したのはなぜだろうか。

結論を先に言えば、ユーザーによるWebページの共有促進がFirefox Screenshotsの主な目的だ。スクリーンショットの撮影はそのための手段に過ぎない。これは「スクショ」をページのシェアに使うライトユーザー向けのツールなのである。

Firefox Screenshotsの狙いは、GitHubのIssue #1で確認できる。2014年12月15日に立てられた最初のイシューで、同機能のTech Leadを現在務めるIan Bicking氏は、Webページを共有する方法を改善したいと述べている。最初期にはページを(装飾抜きで)そのままMozillaのサーバ上に保存するというコンセプトが示され、簡易版Evernoteのような感じだったが、Mozilla UXチームの調査結果を踏まえて方針が転換されることになった。

Mozilla UXチームが2015年1月に実施した調査によれば、コンテンツを保存・共有・管理するツールとしてPocketやEvernoteを使う人は少数派であり、多数の人はもっと基本的なツールであるメール、ローカルストレージ、テキストメッセージ、スクリーンショットなどを使用しているが、そうした人は自分が使っているツールに満足していない。ここから分かるのは、Evernote側に寄せるとユーザーが慣れていないので、敷居が高くなるということだ。そこで、同年4月までにはスクリーンショットをサーバ上に保存して共有する今のスタイルに落ち着いた。"PageShot"の名称もこのころから用いられている。

コンセプトは固まったものの、開発チームは少数であり、実際の形になるまでかなりの時間がかかった。Test Pilotの1プロジェクトとして"Page Shot"が公開されたときには、2016年9月も終わろうとしていた。Test Pilotでの実験期間も長く、2017年7月13日まで続けられた。それだけ試行錯誤したわけだ。

Page ShotはFirefox本体に搭載されるにあたってFirefox Screenshotsへと名称が変更され、Nightlyチャンネルには2017年5月下旬に投入されている。そのころの様子はFirefox Screenshots integrated in Firefox Nightly - gHacks Tech Newsに詳しいが、現在のバージョンとは違って、フルページや表示領域全体のスクリーンショットを撮影する機能もあった。

現行のFirefox ScreenshotsはTest Pilot版とも若干違っている。Page Shotで以下のように特筆されていた機能のうち、スマート検索は見当たらなくなっている。

  • グリッド表示: 保存されたスクリーンショットのサムネイルを閲覧
  • スマート検索: 探しているスクリーンショットをキーワードで見つけ出せます。Page Shotはページタイトルやスクリーンショット内の文字をインデックスします
  • ワンステップ共有: ブラウザーウィンドウ上部から直接、スクリーンショットをソーシャルメディアへ投稿したり、共有可能なリンクをコピーしたりできます

いったん実装されたが後に削られた機能は、ページの保存や管理にとっては有用だが、ページの共有にとってはそれほど有用でないものであったと考えられる。たくさん選択肢があるとその分わかりづらくなってしまう。ライトユーザーの使いやすさを優先し、本当に必要な機能だけに絞り込んだのが現行版というわけだ。

こうしたコンセプトや経緯を知ったうえで眺めてみると、1.スクリーンショットのタイトルにページのタイトルを用いていること、2.SNSやメールでスクリーンショットを共有する機能があること、3.共有リンクにアクセスすれば誰でもスクリーンショットを見られること、4.撮影時に共有リンクがクリップボードにコピーされることといった仕様が、すべて意味のあるものだとわかるだろう。どれもシェアを後押ししている。そして、Snapchatほど極端ではないにせよ、シェアという目的を果たしさえすれば、古いスクショを残しておく必要はない。だからこそ、その保存期間は初期設定で14日に設定されているのだ。

f:id:Rockridge:20170829005326p:plain