Mozilla Flux Mozilla関係の情報に特化したブログです。 2018-09-09T23:06:38+09:00 Rockridge Hatena::Blog hatenablog://blog/6435922169449518567 ブラウザの「更新の確認は行わない」設定をFirefox 63で削除 hatenablog://entry/10257846132625458914 2018-09-09T23:06:38+09:00 2018-09-09T23:10:36+09:00 Firefox本体のアップデートに関して、現行のFirefox 62には3つの設定がある。オプション画面の〔一般〕セクションをスクロールしていくと見つかるが、1)更新を自動的にインストールする、2)更新の確認は行うが、インストールするかを選択する、3)更新の確認は行わない、となっている。初期設定は1)だが、3)への変更も容易なのが現状だ。Firefox 63ではこの3)の設定を削除し、1)と2)だけとする(Bug 1420514)。app.update.enabledの設定そのものが削除されたため、about:configから復活させることもできない。Mozillaの狙いは、ユーザーにできるだ… <p>Firefox本体のアップデートに関して、現行のFirefox 62には3つの設定がある。オプション画面の〔一般〕セクションをスクロールしていくと見つかるが、1)更新を自動的にインストールする、2)更新の確認は行うが、インストールするかを選択する、3)更新の確認は行わない、となっている。初期設定は1)だが、3)への変更も容易なのが現状だ。Firefox 63ではこの3)の設定を削除し、1)と2)だけとする(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1420514" title="1420514 - Remove or hide the update features in the preferences">Bug 1420514</a>)。app.update.enabledの設定そのものが削除されたため、about:configから復活させることもできない。</p><p>Mozillaの狙いは、ユーザーにできるだけ最新バージョンのFirefoxを使ってもらうことにある。Firefox Public Data Reportの<a href="https://data.firefox.com/dashboard/user-activity" title="User Activity | Firefox Public Data Report">User Activity</a>によれば、リリース直後を除くと、デスクトップ版Firefoxの最新バージョンを利用しているユーザーの割合は75%程度にとどまる。残り25%は理由があってアップデートを留保しているのかもしれないが、そうでない場合も多いはず。たとえば、以前「更新の確認は行わない」設定に変更したまま忘れているといったケースだ。こうしたユーザーは気付かないうちにアップデートから取り残されてしまう。しかし、旧式の拡張機能のサポートが打ち切られ、プラグインもFlashに絞られた今、Firefox本体のアップデートをオフにする積極的な理由を持つのは、主に組織内ユーザーに限られよう。</p><p><figure class="figure-image figure-image-fotolife" title="デスクトップ版Firefoxの最新バージョンの利用率。80%を超えることはない。"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180909/20180909220450.png" alt="f:id:Rockridge:20180909220450p:plain" title="f:id:Rockridge:20180909220450p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>デスクトップ版Firefoxの最新バージョンの利用率。80%を超えることはない。</figcaption></figure></p><p>そこで、Mozillaは前述のとおり本体アップデートの確認すら行わない設定を排除する一方で、従来延長サポート版(ESR)でのみサポートしていた本体アップデート無効のポリシーを、Firefox 62からは通常版にも開放した(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1460082" title="1460082 - Allow DisableAppUpdate and DisableSystemAddonUpdate policies outside of the ESR">Bug 1460082</a>)。組織内ユーザーのニーズに配慮した形だ。ポリシー設定の方法などについては、<a href="https://www.clear-code.com/blog/2018/5/12.html" title="Mozilla Firefox ESR60でのPolicy Engineによるポリシー設定の方法と設定項目のまとめ - ククログ(2018-05-12)">Mozilla Firefox ESR60でのPolicy Engineによるポリシー設定の方法と設定項目のまとめ - ククログ(2018-05-12)</a>が詳しい。また、UIが日本語化されていないものの、<a href="https://addons.mozilla.org/ja/firefox/addon/enterprise-policy-generator/" title="Enterprise Policy Generator – Firefox 向けアドオン">Enterprise Policy Generator</a>という拡張機能を使えば、グループポリシーの定義ファイル(policies.json)を手軽に作成できる。</p><p>Firefoxの最新バージョンはその時点で最も安全であり、Firefox Quantum以降の傾向に照らすと最も高速でもある。Mozillaは最新バージョンをリリース後、できるだけ早くユーザーに提供する取り組みを今後も続けていく。その取り組みの1つが現在開発中の<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1343669" title="1343669 - (update-agent) Update Agent tracking bug">Update Agent</a>の導入であり、Firefoxが起動していないときにバックグラウンドで更新のチェックとインストールを実行するというものだ。これによって、いったんFirefoxを起動しないとアップデートが行われない問題が解消される<a href="#f-624c3c8f" name="fn-624c3c8f" title="余談だが、Firefoxの起動中に更新のインストールまで終える仕組みは、Windows版ではFirefox 55で、Mac版とLinux版ではFirefox 57で、それぞれ無効化された(Bug 1370576、Bug 1397562)。再起動後の動作に支障が生じたためだ。Firefoxが起動していないときにアップデートの適用が可能になれば、起動中にそれを行う必要性は低下する。">*1</a>。実のところ前述したFirefox 63の仕様変更は、Update Agentがプロファイルを見なくても本体更新が無効かどうかを判別できるようにする取り組みの一環でもあるのだ。アップデートが迅速に行き渡る環境が整った暁には、更新チェックの頻度も<a href="https://chuttenblog.wordpress.com/2018/07/06/when-do-all-firefox-users-update/" title="When do All Firefox Users Update? – chuttenblog">現在の12時間おきから短縮される</a>だろう。</p> <div class="footnote"> <p class="footnote"><a href="#fn-624c3c8f" name="f-624c3c8f" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">余談だが、Firefoxの起動中に更新のインストールまで終える仕組みは、Windows版ではFirefox 55で、Mac版とLinux版ではFirefox 57で、それぞれ無効化された(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1370576" title="1370576 - [e10s] Unusable nightly after updating with a staged update">Bug 1370576</a>、<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1397562" title="1397562 - On OS X and Linux disable update staging via the app.update.staging.enabled preference">Bug 1397562</a>)。再起動後の動作に支障が生じたためだ。Firefoxが起動していないときにアップデートの適用が可能になれば、起動中にそれを行う必要性は低下する。</span></p> </div> Rockridge Firefoxのアクティブユーザー数やアドオン利用率などが公開 hatenablog://entry/10257846132620467373 2018-09-05T00:59:49+09:00 2018-09-05T01:04:30+09:00 Mozillaは稼働中のFirefoxから技術的な対話データを収集しているが、最近、その膨大なデータを基にFirefox Public Data Reportを公開した。Let’s be Transparent - The Mozilla Blogや上記サイト内の説明によれば、既に2年前から存在するFirefox Hardware Reportを大幅に拡張したもので、3つのセクションに分かれて統計資料が掲載されており、データは毎週更新されるという。今のところデスクトップ版Firefoxのみが対象となっているけれども、そう遠くないうちにモバイル版の資料も加わるようだ。初期設定では全世界(Worl… <p>Mozillaは稼働中のFirefoxから技術的な対話データを収集しているが、最近、その膨大なデータを基に<a href="https://data.firefox.com/" title="Firefox Public Data Report">Firefox Public Data Report</a>を公開した。<a href="https://blog.mozilla.org/blog/2018/08/28/lets-be-transparent/" title="Let’s be Transparent - The Mozilla Blog">Let’s be Transparent - The Mozilla Blog</a>や上記サイト内の説明によれば、既に2年前から存在するFirefox Hardware Reportを大幅に拡張したもので、3つのセクションに分かれて統計資料が掲載されており、データは毎週更新されるという。今のところデスクトップ版Firefoxのみが対象となっているけれども、そう遠くないうちにモバイル版の資料も加わるようだ。</p><p>初期設定では全世界(Worldwide)の資料が表示される。ブラジル、中国、フランス、ドイツ、インド、インドネシア、イタリア、ポーランド、ロシアそして米国の10か国については、個別の資料を見ることもできる。Firefox Public Data Reportは、報道関係者や研究者が参照することはもちろん、Mozillaによるデータの使い方をユーザーに広く知らせる手段ともなることが期待されている。</p><p>3つのセクションを順に紹介しよう。1つ目は<a href="https://data.firefox.com/dashboard/user-activity" title="User Activity | Firefox Public Data Report">User Activity</a>である。デスクトップ版Firefoxの利用者数や日々の利用時間、新規プロファイルの作成率、最新版の利用割合などが掲載されている。注目すべきはFirefoxの月間アクティブユーザー数(MAU)だろう。過去28日間においてアクティブであったデスクトップクライアントの数を計測したもので、本記事執筆時点では、2017年4月1日からの推移がグラフ化されている。ちなみに、2018年9月1日現在のMAUは2億5834万8840クライアントだ。</p><p><figure class="figure-image figure-image-fotolife" title="デスクトップ版FirefoxのMAUとその推移"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180905/20180905001452.png" alt="f:id:Rockridge:20180905001452p:plain" title="f:id:Rockridge:20180905001452p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>デスクトップ版FirefoxのMAUとその推移</figcaption></figure></p><p>2つ目は<a href="https://data.firefox.com/dashboard/usage-behavior" title="Usage Behavior | Firefox Public Data Report">Usage Behavior</a>である。利用者数の多い言語、トラッキング防止機能の常時有効化率(2018年9月1日現在で1.282%)、アドオン利用率などが掲載されている。最後のアドオン利用率は、ユーザーが1つでも(プラグインを除く)アドオンをインストールしているとカウントされるようだ。2018年9月1日現在で34.577%となっているが、Firefox Quantumのリリース前後でさほど変化がないのは興味深い。</p><p><figure class="figure-image figure-image-fotolife" title="デスクトップ版Firefoxのアドオン利用率"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180905/20180905002621.png" alt="f:id:Rockridge:20180905002621p:plain" title="f:id:Rockridge:20180905002621p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>デスクトップ版Firefoxのアドオン利用率</figcaption></figure></p><p>利用者数の多いアドオンのトップ10も掲載されており、広告ブロック系の拡張機能を利用しているユーザーが多いことがわかる。</p><p><figure class="figure-image figure-image-fotolife" title="著名アドオントップ10"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180905/20180905002728.png" alt="f:id:Rockridge:20180905002728p:plain:w400" title="f:id:Rockridge:20180905002728p:plain:w400" class="hatena-fotolife" style="width:400px" itemprop="image"></span><figcaption>著名アドオントップ10</figcaption></figure></p><p>3つ目は<a href="https://data.firefox.com/dashboard/hardware" title="Hardware Across the Web | Firefox Public Data Report">Hardware Across the Web</a>である。従前はこのセクションに該当する項目だけが公開されていた。Firefoxユーザーの利用環境をまとめたもので、GPUモデル、GPUベンダー、ディスプレイ解像度、CPUベンダー、CPUコア数、CPU動作周波率、メモリ容量、利用OS、Flashプラグインの有効化率などが掲載されている。</p><p>ややデータが古くて2018年5月27日現在のものではあるが、CPUは圧倒的にIntel製が多く、OSはトップのWindows 7と次点のWindows 10で約8割を占め、Flashはいまだにほぼ6割の環境で有効化されていることがわかる。</p><p><figure class="figure-image figure-image-fotolife" title="デスクトップ版Firefoxの利用環境"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180905/20180905003913.png" alt="f:id:Rockridge:20180905003913p:plain" title="f:id:Rockridge:20180905003913p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>デスクトップ版Firefoxの利用環境</figcaption></figure></p><p>64bit版と32bit版の利用率の推移も見逃せない。Windows向け64bit版Firefoxのアップデート提供が始まる前、利用割合は64bit版が2割弱、32bit版が8割強という比率になっていた。アップデートの提供開始を機にその比率が急速に逆転したものの、64bit版の伸びが止まり、近時は64bit版が7割、32bit版が3割で安定している。</p><p><figure class="figure-image figure-image-fotolife" title="64bit版と32bit版の利用割合"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180905/20180905004432.png" alt="f:id:Rockridge:20180905004432p:plain" title="f:id:Rockridge:20180905004432p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>64bit版と32bit版の利用割合</figcaption></figure></p><p>今のところローカライズはされておらず、日本語版Firefox固有のデータが存在しない点もやや残念だが、Firefox Public Data Reportにおいて公開されている各種資料は、今後Firefoxに関する議論や考察を進めるうえで不可欠の材料となるだろう。</p> Rockridge Firefox 64本体からフィード購読機能を削除 代替は拡張機能へ hatenablog://entry/10257846132614805631 2018-08-26T23:55:49+09:00 2018-08-26T23:57:34+09:00 2018年12月11日(米国時間)リリース予定のFirefox 64では、RSS/Atomフィードの購読機能とライブブックマーク機能が本体から削除される(Bug 1477667)。その理由は"Removing feed support from Firefox"に詳しいが、要約すると、Firefoxユーザーの99.9%が使用しない機能でフィード自体も廃れつつあるので、デスクトップ版専用の古いコードをメンテナンスしていくコストが釣り合わなくなったというものだ。当初はFirefox 63で削除する話も出ていたが、作業量とタイミングの兼ね合いで見送られた。ライブブックマーク機能の削除に伴い、既存のラ… <p>2018年12月11日(米国時間)リリース予定のFirefox 64では、RSS/Atomフィードの購読機能とライブブックマーク機能が<a href="https://support.mozilla.org/en-US/kb/feed-reader-replacements-firefox" title="Feed reader replacements for Firefox | Firefox Help">本体から削除される</a>(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1477667" title="1477667 - [meta] Remove feed reader and live bookmarks support from Firefox">Bug 1477667</a>)。その理由は&quot;<a href="https://docs.google.com/document/d/1aIMPZVy33mn34pXBUETk4lt_NrJXupcMilTPFFVpmnI/edit">Removing feed support from Firefox</a>&quot;に詳しいが、要約すると、Firefoxユーザーの99.9%が使用しない機能でフィード自体も廃れつつあるので、デスクトップ版専用の古いコードをメンテナンスしていくコストが釣り合わなくなったというものだ。当初はFirefox 63で削除する話も出ていたが、作業量とタイミングの兼ね合いで<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1477674#c3">見送られた</a>。</p><p>ライブブックマーク機能の削除に伴い、既存のライブブックマークは自動的にOPMLファイルに変換して保存され、個別の記事はそのURLのブックマークへと置き換えられる(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1477672" title="1477672 - Migrate existing live bookmarks in order to keep user data">Bug 1477672</a>)。Firefoxが生成したOPMLファイルを別のフィードサービスに読み込ませれば、引き続き購読が可能だ。</p><p>また、本体からフィード関連機能が削除されたとはいっても、拡張機能によって代替できなくなったわけではない。Mozilla自身、おすすめの拡張機能を<a href="https://addons.mozilla.org/ja/firefox/collections/mozilla/refined-reading/" title="Refined Reading – Firefox 向けアドオン">コレクションの形で公開している</a>。たとえば<a href="https://addons.mozilla.org/ja/firefox/addon/livemarks/" title="Livemarks – Firefox 向けアドオン">Livemarks</a>を使えばライブブックマーク機能を事実上維持することができるので、今からこちらに乗り換えておくのも手だろう。単にフィードの購読だけなら<a href="https://addons.mozilla.org/ja/firefox/addon/awesome-rss/" title="Awesome RSS – Firefox 向けアドオン">Awesome RSS</a>という拡張機能もある。</p><p>RSS/Atomフィードそのものの存在感が低下している中、Mozillaの措置はやむを得ないものだろうが、一抹の寂しさを覚えるのも事実だ。なお、Thunderbirdは独自にフィード購読機能を実装しているため、<a href="http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/2018-July/001252.html" title="[Maildev] Mozilla removing RSS - Thunderbird as well?">影響を受けない</a>。</p> Rockridge Firefox 63に複数タブの選択・操作機能が実装される見込み hatenablog://entry/10257846132603613002 2018-07-22T22:30:27+09:00 2018-08-03T10:34:32+09:00 Firefox 56まで、複数のタブを選択してそれらをブックマークしたり、選択したタブ以外を閉じたりする操作は、拡張機能を導入することによって実現できていた。だが、Firefox Quantumのリリースに伴い、WebExtensionsベースの拡張機能は本体の操作とシームレスな形では複数タブの選択・操作ができなくなっており、たとえばマルチプルタブハンドラを導入しても、タブバー上のタブを選択することはできず、拡張機能用のパネルを使って擬似的な操作ができるにとどまる。Firefox 63では、複数タブの選択・操作機能がネイティブに実装され、初期設定で有効化される見通しであり、上記の問題の解消が期… <p>Firefox 56まで、複数のタブを選択してそれらをブックマークしたり、選択したタブ以外を閉じたりする操作は、拡張機能を導入することによって実現できていた。だが、Firefox Quantumのリリースに伴い、WebExtensionsベースの拡張機能は本体の操作とシームレスな形では複数タブの選択・操作ができなくなっており、たとえば<a href="https://addons.mozilla.org/ja/firefox/addon/multiple-tab-handler/" title="マルチプルタブハンドラ (Multiple Tab Handler) – Firefox 向けアドオン">マルチプルタブハンドラ</a>を導入しても、タブバー上のタブを選択することはできず、拡張機能用のパネルを使って擬似的な操作ができるにとどまる。</p><p>Firefox 63では、複数タブの選択・操作機能がネイティブに実装され、初期設定で有効化される見通しであり、上記の問題の解消が期待できる(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1474938" title="1474938 - Enable the multiselect tabs feature by default for release and beta builds">Bug 1474938</a>)。すでにNightlyチャンネルでは有効化済みだ(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1474704" title="1474704 - Enable the multiselect tabs feature by default on Nightly builds">Bug 1474704</a>)。該当する設定はbrowser.tabs.multiselectで、<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1458007" title="1458007 - Allow multiselect operations on tabs">Bug 1458007</a>がメタバグ、つまり関連する一連のバグの基点となっている。</p><p><figure class="figure-image figure-image-fotolife" title="タブの複数選択機能"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180722/20180722213429.png" alt="f:id:Rockridge:20180722213429p:plain" title="f:id:Rockridge:20180722213429p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>複数タブの選択・操作機能</figcaption></figure></p><p>タブの選択にはShiftキーとCtrl/Cmdキーを用いる。Shiftキーで範囲選択、Ctrl/Cmdキーで個別選択という使い分けだが、範囲選択後にShiftキー+Ctrl/Cmdキーを押しながら選択範囲を拡張することもできる(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1473187" title="1473187 - Add ability to select multiple tabs using both Shift + Ctrl/Cmd at the same time">Bug 1473187</a>)。選択したタブは最上部の色が変わるようになっており、アクティブでないタブ上にカーソルをホバーさせた場合であっても、未選択のタブとは区別が可能だ。</p><p><figure class="figure-image figure-image-fotolife" title="タブの選択とカーソルのホバー"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180722/20180722213646.png" alt="f:id:Rockridge:20180722213646p:plain" title="f:id:Rockridge:20180722213646p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>タブの選択とカーソルのホバー</figcaption></figure></p><p>本記事執筆時点で実装済みの操作を列挙しておこう。これらの操作は、タブのコンテキストメニューから項目を選択することによって行えるが、今後はショートカットも実装されていく。</p> <ul> <li>選択したタブを閉じる(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1458022" title="1458022 - Implement ability to close a selection of tabs">Bug 1458022</a>)</li> <li>選択外のタブをすべて閉じる(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1472910" title="1472910 - In a multiselect context, close other tabs should close all except the multi-selected tabs.">Bug 1472910</a>)</li> <li>選択したタブをブックマーク(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1458067" title="1458067 - Implement ability to bookmark a selection of tabs">Bug 1458067</a>)</li> <li>選択したタブを再読み込み(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1458061" title="1458061 - Implement ability to reload a selection of tabs">Bug 1458061</a>)</li> <li>選択したタブをピン留め・選択したタブのピン留めを外す(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1458060" title="1458060 - Implement ability to pin/unpin a selection of tabs">Bug 1458060</a>)</li> <li>(選択した)タブをミュート・タブのミュートを解除(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1458039" title="1458039 - Implement ability to mute/unmute a selection of tabs">Bug 1458039</a>)</li> <li>(選択したタブを)新しいウィンドウへ移動(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1458049" title="1458049 - Implement ability to move a selection of tabs into a new window through tab context menu">Bug 1458049</a>)</li> </ul><p><figure class="figure-image figure-image-fotolife" title="タブの複数選択機能の実装により拡張されたコンテキストメニュー"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180722/20180722220025.png" alt="f:id:Rockridge:20180722220025p:plain:w300" title="f:id:Rockridge:20180722220025p:plain:w300" class="hatena-fotolife" style="width:300px" itemprop="image"></span><figcaption>タブの複数選択機能の実装により拡張されたコンテキストメニュー</figcaption></figure></p><p>また、近い将来に以下の操作が実装される予定だ。なお、複数タブの選択時に新規タブを開いた場合、選択が解除されるようになる(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1475693" title="1475693 - In a multi-select context, opening a new tab should clear the selection">Bug 1475693</a>)。</p> <ul> <li>(選択した)タブを端末へ送信(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1470555" title="1470555 - Implement ability to send a selection of tabs">Bug 1470555</a>)</li> <li>選択したタブをタブバー上のドラッグ&ドロップで移動させる(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1458066" title="1458066 - Implement ability to move a selection of tabs within the same window through drag and drop">Bug 1458066</a>)</li> <li>選択したタブをドラッグ&ドロップで別のウィンドウに移動させる(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1458056" title="1458056 - Implement ability to move a selection of tabs into another window through drag and drop">Bug 1458056</a>)</li> </ul><p>複数タブの選択・操作機能がインストールした直後から使えるのは、たとえばChromeに対するアドバンテージとなるだろう。Firefox 56以前の使い勝手を求めるユーザーにとっても朗報と言える。実装される操作も上記で打ち止めというわけではないだろうから、マルチプルタブハンドラが実現していた、「選択したタブをドラッグ&ドロップで既存のブックマークフォルダにまとめてブックマークする」操作も追加される可能性はありそうだ。</p><p><em>(18/08/03追記)</em><br>タブバー上のコンテキストメニューの項目が固まってきたようだ。本追記時点の最新スペックは以下のようになっている。<figure class="figure-image figure-image-fotolife" title="タブ選択時のコンテキストメニュー"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180803/20180803103228.png" alt="f:id:Rockridge:20180803103228p:plain" title="f:id:Rockridge:20180803103228p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>タブ選択時のコンテキストメニュー(2018年8月2日時点)</figcaption></figure></p> Rockridge タブの切り替えをスムーズにするTab Warming機能について(Firefox 61以降) hatenablog://entry/10257846132601378755 2018-07-15T17:05:19+09:00 2018-07-15T17:05:19+09:00 Windows版・Linux版Firefox 61では、Tab Warmingと呼ばれる機能が有効化されている(Bug 1456602)*1。タブを切り替える前にいわばウォームアップを済ませておく機能で、ユーザーに見えないところで処理を先取りするため、結果的にタブの切り替え処理が速くなったように感じられる。タブ切り替えのウォームアップとは具体的に何だろうか。現行のFirefoxはマルチプロセス化されているので、タブを切り替える場合、メインプロセスから切り替え先のタブを司るcontentプロセスに対し、レイヤーツリーを生成するよう指示が出され、その結果がcompositorプロセスに送られて合成… <p>Windows版・Linux版Firefox 61では、Tab Warmingと呼ばれる機能が有効化されている(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1456602" title="1456602 - Let tab warming ride to release for Windows and Linux">Bug 1456602</a>)<a href="#f-8d2c53ed" name="fn-8d2c53ed" title="macOS版でも、タブ上のアニメーションが遅くなるバグが解消され次第、有効化される見通し。">*1</a>。タブを切り替える前にいわばウォームアップを済ませておく機能で、ユーザーに見えないところで処理を先取りするため、結果的にタブの切り替え処理が速くなったように感じられる。</p><p>タブ切り替えのウォームアップとは具体的に何だろうか。現行のFirefoxはマルチプロセス化されているので、タブを切り替える場合、メインプロセスから切り替え先のタブを司るcontentプロセスに対し、レイヤーツリーを生成するよう指示が出され、その結果がcompositorプロセスに送られて合成(Compositing)の処理が行われる<a href="#f-a448746b" name="fn-a448746b" title="Firefox QuantumのOff Main Thread Painting(OMTP)とRetained Display Listsについて - Mozilla Flux参照">*2</a>。ウォームアップとは、この一連の流れをタブの切り替えが行われる前から開始しておくという意味だ。その後タブの切り替えが実行されなかったときは、レイヤーツリーは捨てられる。</p><p>ウォームアップが開始されるタイミングは複数ある。代表的なのは、切り替え先のタブ上にカーソルがホバーしたとき(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1385453" title="1385453 - Make it possible for async tab switcher to &quot;warm up&quot; tabs that are likely to be displayed soon">Bug 1385453</a>)と、タブを閉じるボタン上にカーソルがホバーしたとき(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1430292" title="1430292 - Warm up tab we'd switch to when hovering a tab close icon">Bug 1430292</a>)である。そのほか、Ctrl+Tabパネルを表示させたとき(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1430153" title="1430153 - Warm up tabs in the Ctrl+Tab panel">Bug 1430153</a>)やマウスの中ボタンの押下を検出したとき(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1472230" title="1472230 - Warm up tab we'd switch to when mousedown'ing with the middle mouse button">Bug 1472230</a>:ただしFirefox 63から)も対象だ。いずれも手動または自動でタブが切り替わる直前の操作が選ばれている。</p><p>Tab Warming機能の性質上、レンダリング処理に時間のかかるWebページほど効果を発揮しやすい。もっとも、タブの切り替えに要する時間は、平均値・中央値ともに減少することが判明しており、特別なケースでなくともユーザーはメリットを享受できる。ちなみに、browser.tabs.remote.warmup.maxTabsの設定値(デフォルトは3)を変更することで、効果範囲の調節も可能だ。</p><p><figure class="figure-image figure-image-fotolife" title="タブ切り替え時間の平均値(Mean)と中央値(Median)が低下"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180715/20180715164711.png" alt="f:id:Rockridge:20180715164711p:plain" title="f:id:Rockridge:20180715164711p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>タブ切り替え時間の平均値(Mean)と中央値(Median)が低下</figcaption></figure></p><p><div class="refList"></p> <ul> <li><a href="https://mail.mozilla.org/pipermail/firefox-dev/2018-April/006396.html" title="Intent to Ship: Tab Warming (Windows and Linux)">Intent to Ship: Tab Warming (Windows and Linux)</a></li> <li><a href="https://mikeconley.ca/blog/2018/01/11/making-tab-switching-faster-in-firefox-with-tab-warming/" title="Making tab switching faster in Firefox with tab warming | Mike Conley's Blog">Making tab switching faster in Firefox with tab warming | Mike Conley's Blog</a></li> <li><a href="https://www.publickey1.jp/blog/18/firefoxtab_warming.html" title="Firefox、ブラウザタブの切り替えをさらに高速化する「Tab Warming」機能を試験実装。マウスホバーの時点でレンダリング開始 - Publickey">Firefox、ブラウザタブの切り替えをさらに高速化する「Tab Warming」機能を試験実装。マウスホバーの時点でレンダリング開始 - Publickey</a></li> </ul><p></div></p> <div class="footnote"> <p class="footnote"><a href="#fn-8d2c53ed" name="f-8d2c53ed" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">macOS版でも、<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1453080" title="1453080 - Tab warming causes janky tab hover animations">タブ上のアニメーションが遅くなるバグ</a>が解消され次第、有効化される見通し。</span></p> <p class="footnote"><a href="#fn-a448746b" name="f-a448746b" class="footnote-number">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text"><a href="https://rockridge.hatenablog.com/entry/2018/01/28/224925" title="Firefox QuantumのOff Main Thread Painting(OMTP)とRetained Display Listsについて - Mozilla Flux">Firefox QuantumのOff Main Thread Painting(OMTP)とRetained Display Listsについて - Mozilla Flux</a>参照</span></p> </div> Rockridge タブのダブルクリックで現在表示させているタブを閉じる小技(Firefox 61以降) hatenablog://entry/10257846132599346371 2018-07-08T22:17:37+09:00 2018-07-16T08:26:05+09:00 Firefox 61以降、以下の手順で本体の設定を変更すると、タブのダブルクリックによって現在表示させている(=アクティブな)タブを閉じることができる(Bug 1435142)。 アドレスバーに"about:config"と打ち込んでページを開き、「動作保証対象外になります!」という警告が出たときは、「危険性を承知の上で使用する」をクリックして先へ進む。 検索欄にbrowser.tabs.closeTabByDblclickを入力し、ヒットした設定名をクリックして真偽値をtrueに変更する。 通常、タブを閉じる際はタブの右端にある「×」マークをクリックする。上記の設定をすれば、アクティブなタブ… <p>Firefox 61以降、以下の手順で本体の設定を変更すると、タブのダブルクリックによって現在表示させている(=アクティブな)タブを閉じることができる(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1435142" title="1435142 - Pref to enable close selected tab by dblclicking it">Bug 1435142</a>)。</p> <ol> <li>アドレスバーに"about:config"と打ち込んでページを開き、「動作保証対象外になります!」という警告が出たときは、「危険性を承知の上で使用する」をクリックして先へ進む。</li> <li>検索欄に<strong>browser.tabs.closeTabByDblclick</strong>を入力し、ヒットした設定名をクリックして真偽値をtrueに変更する。</li> </ol><p>通常、タブを閉じる際はタブの右端にある「×」マークをクリックする。上記の設定をすれば、アクティブなタブに限りダブルクリックで閉じることができるので、手間が省けるわけだ。対象をアクティブなタブに限定しているのは、タブ切り替え時に誤ってタブを閉じてしまう事故を防ぐためである。</p><p>タブを閉じる作業を効率よく行うという意味では、マウスジェスチャ系の拡張機能を入れるほうがよいかもしれない。だが、WebExtensionsの制約によって、読み込み途中のページや一部のページではマウスジェスチャが効かない。そんな場合でも、本機能はFirefox本体に搭載されたものなので動作する。併用も選択肢のうちだろう。</p> Rockridge Firefox 61でRetained Display Listsが段階的に有効化 hatenablog://entry/17391345971658048960 2018-06-26T23:57:23+09:00 2018-06-27T00:01:33+09:00 Firefox 61のリリース後、当初は無効となっているRetained Display Lists(以下RDL)という機能が有効化されていく(Bug 1467514)。現在の計画では、リリースの2日後にまず25%のユーザーが対象となる。1週間様子を見てから対象を50%に拡大し、さらに1週間様子を見て100%に引き上げるという。RDLについては、今年の1月にFirefox QuantumのOff Main Thread Painting(OMTP)とRetained Display Listsについて - Mozilla Fluxで紹介した。再描画の処理を軽減する仕組みであり、余力をJavaS… <p>Firefox 61のリリース後、当初は無効となっているRetained Display Lists(以下RDL)という機能が有効化されていく(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1467514" title="1467514 - Gradual rollout of retained-dl for Fx61 via Normandy after release">Bug 1467514</a>)。<a href="https://groups.google.com/forum/#!topic/mozilla.dev.platform/lz3H5sitJCY" title="Intent to ship: Retained Display Lists (rollout plan)">現在の計画</a>では、リリースの2日後にまず25%のユーザーが対象となる。1週間様子を見てから対象を50%に拡大し、さらに1週間様子を見て100%に引き上げるという。</p><p>RDLについては、今年の1月に<a href="https://rockridge.hatenablog.com/entry/2018/01/28/224925" title="Firefox QuantumのOff Main Thread Painting(OMTP)とRetained Display Listsについて - Mozilla Flux">Firefox QuantumのOff Main Thread Painting(OMTP)とRetained Display Listsについて - Mozilla Flux</a>で紹介した。再描画の処理を軽減する仕組みであり、余力をJavaScriptの処理やレイアウトの実行、入力イベントへの応答などに回せるので、Webページの応答性が向上する。</p><p><a href="https://hacks.mozilla.org/2018/06/retained-display-lists/" title="Retained Display Lists for improved page performance – Mozilla Hacks – the Web developer blog">Retained Display Lists for improved page performance – Mozilla Hacks</a>によれば、MozillaがFirefox 60 Betaのユーザーを対象に行ったテストの結果、RDLを有効化すると描画処理に要する時間の中央値が、4.5ミリ秒から3ミリ秒へと減少したとのこと。</p><p><figure class="figure-image figure-image-fotolife" title="前半:RDL有効 後半:RDL無効"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180626/20180626234920.png" alt="f:id:Rockridge:20180626234920p:plain" title="f:id:Rockridge:20180626234920p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>〔グラフ〕前半:RDL有効 後半:RDL無効</figcaption></figure></p><p>このように、全体的に見て描画処理に要する時間が3分の2になっただけでなく、16ミリ秒を超える「遅い」描画処理に関しては、ほぼ40%の割合で削減することに成功したという。Firefox 58 Betaの時点ではこの削減割合が「30%近く」にとどまっていたから、その後の改良で効果を増したことがわかる。</p><p>今後もRDLは改良が加えられる見込みだ。RDLが効果を発揮できない、ページ全体の再描画を要する場面を早期に検知できるようにするほか、RDLの準備作業にかかる時間も短縮させる。</p> Rockridge 2019年のFirefoxのリリース予定日 hatenablog://entry/17391345971656085305 2018-06-20T23:48:46+09:00 2019-05-26T20:36:48+09:00 通常版のFirefoxは年に7回、ESR(延長サポート版)は年に1回、メジャーアップデートが実施される。アップデートのリリース間隔は6週間に固定されない変則的なものなので、Mozillaは早い段階でスケジュールを明らかにして、ユーザーがアップデートに備えた計画を立てられるようにしている。ただし、スケジュール公開後もときどき変更が加えられる。Firefox Release Calendar - MozillaWikiに2019年のスケジュールが掲載されているので、リリース版とESRの日程(米国時間が基準)を紹介しておく。便宜上、リリース未了のバージョンについては2018年のスケジュールも記載する… <p>通常版のFirefoxは年に7回、ESR(延長サポート版)は年に1回、メジャーアップデートが実施される。アップデートのリリース間隔は6週間に固定されない変則的なものなので、Mozillaは早い段階でスケジュールを明らかにして、ユーザーがアップデートに備えた計画を立てられるようにしている。ただし、スケジュール公開後もときどき変更が加えられる。</p><p><a href="https://wiki.mozilla.org/Release_Management/Calendar" title="Firefox Release Calendar - MozillaWiki">Firefox Release Calendar - MozillaWiki</a>に2019年のスケジュールが掲載されているので、リリース版とESRの日程(米国時間が基準)を紹介しておく。便宜上、リリース未了のバージョンについては2018年のスケジュールも記載するので、対象バージョンはリリース版のFirefox 61から71までとなる。</p><p>なお、Firefox ESR 60系列の次がESR 68系列となっている。かつては毎年3月に新しいESR系列に移行していたが、7月まで持ち越されることになった。</p><p><table class="benchmark"> <thead> <tr> <th>リリース予定日</th> <th>正式版</th> <th>ESR</th> </tr> </thead> <tbody> <tr> <th>2018-06-26</th> <td>Firefox 61</td> <td>Firefox 52.9; 60.1</td> </tr> <tr> <th>2018-09-05</th> <td>Firefox 62</td> <td>Firefox 60.2</td> </tr> <tr> <th>2018-10-23</th> <td>Firefox 63</td> <td>Firefox 60.3</td> </tr> <tr> <th>2018-12-11</th> <td>Firefox 64</td> <td>Firefox 60.4</td> </tr> <tr> <th>2019-01-29</th> <td>Firefox 65</td> <td>Firefox 60.5</td> </tr> <tr> <th>2019-03-19</th> <td>Firefox 66</td> <td>Firefox 60.6</td> </tr> <tr> <th>2019-05-21</th> <td>Firefox 67</td> <td>Firefox 60.7</td> </tr> <tr> <th>2019-07-09</th> <td>Firefox 68</td> <td>Firefox 60.8; 68.0</td> </tr> <tr> <th>2019-09-03</th> <td>Firefox 69</td> <td>Firefox 60.9; 68.1</td> </tr> <tr> <th>2019-10-22</th> <td>Firefox 70</td> <td>Firefox 68.2</td> </tr> <tr> <th>2019-12-10</th> <td>Firefox 71</td> <td>Firefox 68.3</td> </tr> </tbody> </table></p><p><em>(19/05/26追記)</em><br>元サイトにおけるスケジュール変更を反映させた。</p> Rockridge Mozillaがメリトクラシーを捨てるとき hatenablog://entry/17391345971650831492 2018-06-04T00:41:49+09:00 2018-06-04T00:41:49+09:00 Mozillaはガバナンスのあり方を自ら定義しているのだが、最近、その定義を見直す動きがある。mozilla.governanceフォーラムの"Proposal: Addressing the term “meritocracy” in the governance statement"スレッドで議論が行われている。まずはMozillaのガバナンスのあり方について、現在の定義を見てみよう。 Mozilla is an open source project governed as a meritocracy. Our community is structured as a virtual o… <p>Mozillaはガバナンスのあり方を<a href="https://www.mozilla.org/en-US/about/governance/" title="Governance — Mozilla">自ら定義</a>しているのだが、最近、その定義を見直す動きがある。mozilla.governanceフォーラムの&quot;<a href="https://groups.google.com/forum/#!topic/mozilla.governance/OQlS6-gUBLQ" title="Proposal: Addressing the term “meritocracy” in the governance statement - Google グループ">Proposal: Addressing the term “meritocracy” in the governance statement</a>&quot;スレッドで議論が行われている。</p><p>まずはMozillaのガバナンスのあり方について、現在の定義を見てみよう。</p> <blockquote> <p>Mozilla is an open source project governed as a meritocracy. Our community is structured as a virtual organization where authority is distributed to both volunteer and employed community members as they show their abilities through contributions to the project.</p><p>Mozillaはメリトクラシーを採用するオープンソース・プロジェクトである。我々のコミュニティは仮想的な組織として構築され、そこでの権威は、プロジェクトへの貢献を通じて自らの能力を示すことにより、ボランティアにも雇用されたコミュニティ構成員にも配分される。</p> </blockquote> <p>難しい言い回しだが、かみ砕いて言えば、努力・能力・成果の総体を「メリット」と呼ぶとすると、Mozillaコミュニティはメリットを基準にして運営されていくということだ。コミュニティの構成員はMozilla Corp.の従業員と外部貢献者の双方を含むから、世界中に散らばっているし、外部貢献者に対する業務上の指揮命令関係があるわけでもないので、仮想的な組織とならざるをえない。そして、Mozilla Corp.の従業員の特権は否定されており、メリットを示せば外部貢献者の成果物であっても採用される。</p><p>この説明でもまだ抽象度が高いわけだが、Mozillaの活動が多様であるため、抽象的な概念を使うことなく簡潔にガバナンスのあり方を定義することは難しい。話をわかりやすくするため、Firefoxの開発に焦点を絞ろう。要するに、メリトクラシーを採用すると、Firefoxの機能を改善する優れたコードが提供されるのであれば、Mozilla Corp.の内外を問わず受け入れることになる。</p><p>だが、その一方で、Mozillaはダイバーシティと社会的包摂に関する活動にも力を入れている。&quot;<a href="https://mozilla.github.io/womenandweb/" title="Women and Web Literacy">Women and Web Literacy</a>&quot;と名付けられたプログラムはその一例だ。この観点からは、Firefoxのコードに対する内外の貢献者において、仮に白人男性が7割を占めているとすると、是正を検討する必要が出てくることになる。</p><p>Mozillaが2018年の国際女性デーに合わせて、コードレビュー時のジェンダーバイアスや人種バイアスを減らす実験に取り組んでいることを<a href="https://blog.mozilla.org/blog/2018/03/08/gender-bias-code-reviews/" title="Mozilla experiment aims to reduce bias in code reviews">発表した</a>のも、そうした文脈の中で理解できよう。この実験は、Bugzilla@Mozillaのレビュー申請やGitHubのプルリクエストを匿名化することで、コードレビュー担当者が予断を持ってレビューに臨むことを防ぐというもの。メリットによって評価する際に余計なバイアスがかからないようにするわけだから、これもメリトクラシーの範疇だ。</p><p>そこから先、たとえばMozilla Corp.がプログラマを採用する際に、女性の比率を定めるだとか、特定のエスニック・グループ(黒人やヒスパニックなど)に属する場合は面接で加点するといったアファーマティブ・アクションをとろうとすれば、メリトクラシーとの抵触が問題となる。</p><p>ここまでの予備知識を踏まえてもらったうえで、提案中の新しい定義を紹介しよう。Mozillaはガバナンスのあり方についての定義を、次のように変えようとしている。</p> <blockquote> <p>Mozilla is an open source project. Our community is structured as a virtual organization. Authority is primarily distributed to both volunteer and employed community members as they show their ability through contributions to the project. The project also seeks to debias this system of distributing authority through active interventions that engage and encourage participation from diverse communities.</p><p>Mozillaはオープンソース・プロジェクトである。我々のコミュニティは仮想的な組織として構築される。権威は、主に、プロジェクトへの貢献を通じて自らの能力を示すことにより、ボランティアにも雇用されたコミュニティ構成員にも配分される。プロジェクトは、多様なコミュニティからの参加を呼び込み、促進することによる積極的な介入を通じて、この権威配分のシステムに存在するバイアスを是正することも追求する。</p> </blockquote> <p>この定義に則れば、上記のアファーマティブ・アクションも「権威配分のシステムに存在するバイアスを是正する」ための積極的な介入措置として正当化されるだろう。新定義の提案者は、Mozillaのガバナンスのあり方自体を変えようとは思っておらず、説明の仕方を変えるだけだと述べているが、額面通り受け取ることは難しい。</p><p>Mozillaが営利を追求しないため、Firefoxにユーザーのプライバシーを尊重する機能を積極的に組み込めるというのであれば、ユーザーにとって利益のある話だ。しかし、Firefoxが「政治的に正しい」プロセスによって開発されたからといって、ユーザーがどんな利益を受けるというのだろう。Firefoxがパフォーマンス面でChromeに追いつくためには、メリトクラシーの徹底こそがむしろ求められているのではないか。</p><p>さらに別の疑念が頭をもたげる。「バイアスを是正するための積極的な介入措置」が、プログラマの思想を問題にするようになっていく危険はないだろうか。極端な例を挙げれば、差別主義者がとても優れたコードを書く場合、Mozillaはその貢献を受け入れるのか、ということになるわけだが、実はここで「受け入れない」を選んだ先にこそ真の問題がある。現実には、誰が見ても差別主義者だと判断できるケースは少ないだろう。あるプログラマの過去の発言を捉えて、「彼は女性差別的な発言をしたからMozillaにふさわしくない」との批判が出た際、メリトクラシーに従えば、「彼は優れたコードを書いて貢献してきたからMozillaにふさわしい」と反論できるが、バイアスの是正も追求するとなれば、どうなるかわからない。</p><p>ここで思い出されるのがBrendan Eich氏の顛末だ。Eich氏はMozillaプロジェクトの創設者であり、Mozilla Corp.のCTOを努め、2014年3月24日には同社のCEOに就任したが、強い批判を受けて2週間と経たないうちに<a href="https://blog.mozilla.org/blog/2014/04/03/brendan-eich-steps-down-as-mozilla-ceo/" title="Brendan Eich Steps Down as Mozilla CEO - The Mozilla Blog">辞職を余儀なくされた</a>。Eich氏が2008年に同性婚を禁じるカリフォルニア州憲法改正案に賛成し、1000ドルを寄付した点が、Mozilla Corp.のCEOとして不適格だと批判されたのだ。Eich氏はCEO就任後、&quot;<a href="https://brendaneich.com/2014/03/inclusiveness-at-mozilla/" title="Inclusiveness at Mozilla – Brendan Eich">Inclusiveness at Mozilla</a>&quot;というブログ記事を発表し、ダイバーシティと社会的包摂を尊重した経営を行っていく旨を宣言したのだが、いったん巻き起こった批判が止むことはなかった。</p><p>Mozillaのガバナンスのあり方に関する新定義が発効されれば、同じようなことがもっと広範に起こる可能性も否定できない。この定義は、単なる建て前ではなく、Mozillaの活動の中で常に参照され、活動の方向性の指針となるものだからだ。考えすぎかもしれないが、<a href="https://ja.wikipedia.org/wiki/%E5%BD%BC%E3%82%89%E3%81%8C%E6%9C%80%E5%88%9D%E5%85%B1%E7%94%A3%E4%B8%BB%E7%BE%A9%E8%80%85%E3%82%92%E6%94%BB%E6%92%83%E3%81%97%E3%81%9F%E3%81%A8%E3%81%8D" title="彼らが最初共産主義者を攻撃したとき - Wikipedia">ニーメラーの警句</a>の例もあることなので、あえて記事を起こして記録に残しておく。</p> Rockridge Firefox 60の性能は1年前とは別物 Chromeを視界に捉える hatenablog://entry/17391345971644205034 2018-05-13T22:17:11+09:00 2018-05-13T22:29:15+09:00 当ブログでは、Firefoxの延長サポート版(ESR)のメジャーアップデート時期を開発の区切りとみて、Web上で実行可能なベンチマークの測定結果を公開している。今回は、Firefox 60のパフォーマンスをFirefox 52およびChrome 66と比較する。検証を行った具体的なバージョンを挙げると、32bit版Firefox 52.7.4(ビルドID:20180427222832)、64bit版Firefox 60.0 RC2(ビルドID:20180503143129)、それに64bit版Chrome 66(バージョン:66.0.3359.139)である。Firefox Quantumのリ… <p>当ブログでは、Firefoxの<a href="https://www.mozilla.jp/business/">延長サポート版(ESR)</a>のメジャーアップデート時期を開発の区切りとみて、Web上で実行可能なベンチマークの測定結果を公開している。今回は、Firefox 60のパフォーマンスをFirefox 52およびChrome 66と比較する。</p><p>検証を行った具体的なバージョンを挙げると、32bit版Firefox 52.7.4(ビルドID:20180427222832)、64bit版Firefox 60.0 RC2(ビルドID:20180503143129)、それに64bit版Chrome 66(バージョン:66.0.3359.139)である。Firefox Quantumのリリースに伴ってマルチプロセス機能(e10s-multi)が全面的に有効化され、その前に64bit版への移行も開始された。今回のテストではそれらの点が反映されている。</p><p>動作環境についてだが、OSは64bit版Windows 10 Professional(Fall Creators Update)で、使用したハードウエアは、CPUがIntel Core i7-7500U CPU 2.70GHz、GPUがIntel HD Graphics 620(ドライバのバージョン:21.20.16.4542)、メモリ容量が16.0GB、ストレージがWestern Digital製SATA-IIIのHDDである。GPU描画支援はDirect3D 11、Direct2D 1.1とDirectWriteをバックエンドに使用している。</p><p>測定にあたってブラウザごとに新規プロファイルを用意し、拡張機能のインストールは行わず、テストの中断を防ぐためFirefoxではdom.max_script_run_timeの値を0に設定した。プラグインは、初期設定でインストール・有効化されるものはそのままにして、Shockwave Flash 29.0 r0を有効化している(Firefox 60では「実行時に確認する」の設定)。なお、Firefox 52ではフォントの設定をメイリオに変更した。</p><p>測定の際には<a href="http://ascii.jp/elem/000/001/116/1116651/index-3.html">Turbo Boost機能を無効化</a>し、定格の動作周波数でPCを動作させた。画面サイズは3840×2160で、表示を250%に拡大しており、測定時のウィンドウは最大化された状態である。なお、各ベンチマークの実行後はブラウザを終了させて、メモリ上に前のベンチマークが残らないようにした。</p><p>最後に、対象となるベンチマークは、<a href="https://rockridge.hatenablog.com/entry/2017/03/07/235839" title="速度面でFirefox 52は振るわず Quantumによる飛躍に期待 - Mozilla Flux">前回の記事</a>で用いたものから一部を入れ替えた。</p> <div class="section"> <h4>ページの読み込み速度およびメモリ使用量</h4> <p>10のWebサイトを同時に開いて、読み込み中であることを示すアイコン(throbber)が消えるまでの時間を手動で計測した。秒数の小数点以下は切上げている。同時に、10サイトを表示させた場合と、単サイトを表示した場合のメモリ使用量もチェックした。</p><p>具体的な手順は次のとおり。以下の10サイトをその記載順にフォルダ内にブックマークしたバックアップファイル(FirefoxはJSON形式、ChromeはHTML形式)をインポートし、「タブですべて開く」で10サイトをいっせいに読み込む。throbberが消えるまでの時間を計測し、完了したらFirefoxのホームページは閉じ、各タブをクリックしてWebページを実際に画面に表示させる。つまり最後に表示されるのはWikipedia(日本語版)になる。</p><p><ul> <li><a href="https://www.microsoft.com/ja-jp/">日本マイクロソフト</a> / <a href="https://tabelog.com/">食べログ</a> / <a href="https://www.post.japanpost.jp/index.html">郵便局</a></li> <li><a href="https://www.amazon.co.jp/">Amazon.co.jp</a> / <a href="https://www.youtube.com/">YouTube</a> / <a href="https://www.nhk.or.jp/">NHKオンライン</a> / <a href="https://www.nikkei.com/">日経電子版</a></li> <li><a href="http://hatenablog.com/">はてなブログ</a> / <a href="https://www.yahoo.co.jp/">Yahoo! JAPAN</a> / <a href="https://ja.wikipedia.org/wiki/">Wikipedia(日本語版)</a></li> </ul></p><p>1分間そのまま放置した後、Firefoxでは新しいタブを開いてabout:performanceを呼び出し、&quot;Memory usage of Subprocesses&quot;欄に表示される、Parentつまり親プロセスのResident Set Sizeの値と、その他子プロセスの各Unique Set Sizeの値を合算する<a href="#f-6369ca97" name="fn-6369ca97" title="Are they slim yet, round 2参照">*1</a>。Chromeではメニューの「その他のツール」から「タスク マネージャ」を選択して、各タスクのメモリ使用量を合算する<a href="#f-ede8cba5" name="fn-ede8cba5" title="Firefoxとの単純比較は困難だが、この方法であればChromeのメモリ使用量が過大に出ることはないはず。">*2</a>。</p><p>そして、「他のタブをすべて閉じる」でYahoo! JAPAN以外のWebページはすべて閉じる。5分間<a href="#f-f6756e8b" name="fn-f6756e8b" title="Bug 1188834参照。javascript.options.compact_on_user_inactive_delayの値はその後も変わっていない。">*3</a>そのまま放置した後、再び新しいタブを開き、上記の手順でメモリ使用量を数値を合算する。ブラウザをいったん終了させ、再起動後に上記10サイトを同じ手順で開いて、throbberが消えるまでの時間を計測する。一連の手順を実行した結果を以下に示す。</p><p><table class="benchmark"> <thead> <tr> <th> </th> <th>Firefox 52</th> <th>Firefox 60</th> <th>Chrome 66</th> </tr> </thead> <tbody> <tr class="total"> <th>読込時間(1回目)</th> <td>57 秒</td> <td>15 秒</td> <td>16 秒</td> </tr> <tr class="total"> <th>読込時間(2回目)</th> <td>23 秒</td> <td>15 秒</td> <td>8 秒</td> </tr> </tbody> </table></p><p><table class="benchmark"> <thead> <tr> <th> </th> <th>Firefox 52</th> <th>Firefox 60</th> <th>Chrome 66</th> </tr> </thead> <tbody> <tr class="total"> <th>使用メモリ(10タブ)</th> <td>641.0 MB</td> <td>1011.5 MB</td> <td>970.5 MB </td> </tr> <tr class="total"> <th>使用メモリ(単タブ)</th> <td>459.0 MB </td> <td>600.5 MB</td> <td>222.7 MB</td> </tr> </tbody> </table></p><p>対象としたサイトとの相性が悪いのか、Firefox 52は1回目の読み込みにやたらと時間がかかった。日経電子版のリダイレクト処理が影響したとみられる。Firefox 60とChrome 66は、1回目の読み込みに関しては互角だが、2回目で差がつきChromeが最速となった。</p><p>メモリ使用量に関し、FirefoxとChromeでは測定方法が違うため、比較は難しい。だが、少なくとも拡張機能をインストールしない状態では、Firefoxのほうが省メモリだと言えるだけの根拠は見いだせなかった。Chromeはタブを閉じた後のメモリの解放がスムーズに行われている印象である。</p> </div> <div class="section"> <h4>ストレージ</h4> <p><a href="http://reyesr.github.io/html5-storage-benchmark/">HTML5 Offline Storage Benchmark</a>は、オフラインストレージの性能を計測するベンチマークだ。localStorage、WebSQLおよびIndexedDBを対象にできるが、ここではIndexedDBの結果(主に1ミリ秒あたりに処理されたオペレーション数)を掲載する。</p><p><table class="benchmark"> <thead> <tr> <th> </th> <th>Firefox 52</th> <th>Firefox 60</th> <th>Chrome 66</th> </tr> </thead> <tbody> <tr> <th>Clear</th> <td>22.00 ms</td> <td>14.00 ms</td> <td>59.40 ms</td> </tr> <tr> <th>Inject-L</th> <td>2.08 op/ms</td> <td>2.50 op/ms</td> <td>0.12 op/ms</td> </tr> <tr> <th>Inject-S</th> <td>2.27 op/ms</td> <td>2.94 op/ms</td> <td>0.14 op/ms</td> </tr> <tr> <th>InjectBulk-L</th> <td>1.12 op/ms</td> <td>4.82 op/ms</td> <td>3.06 op/ms</td> </tr> <tr> <th>InjectBulk-S</th> <td>6.54 op/ms</td> <td>5.03 op/ms</td> <td>2.97 op/ms</td> </tr> <tr> <th>Lookup</th> <td>1.67 op/ms</td> <td>6.25 op/ms</td> <td>1.15 op/ms</td> </tr> <tr> <th>Lookup2</th> <td>6.37 op/ms</td> <td>7.78 op/ms</td> <td>3.55 op/ms</td> </tr> </tbody> </table></p><p>ほとんどの項目でFirefox 60はFirefox 52を上回る成績を残し、Chrome 66を圧倒している。</p> </div> <div class="section"> <h4>レイアウトおよび描画処理</h4> <div class="section"> <h5>HTML5 Canvas</h5> <p><a href="http://www.kevs3d.co.uk/dev/canvasmark/">CanvasMark 2013</a> version 1.1は、HTML5ゲームでよく使用される処理(ビットマップ、Canvas描画、αブレンディングなど)に対するレンダリング・パフォーマンスをテストする。</p><p><table class="benchmark"> <thead> <tr> <th> </th> <th>Firefox 52</th> <th>Firefox 60</th> <th>Chrome 66</th> </tr> </thead> <tbody> <tr class="total"> <th>CanvasMark Score</th> <td>8583</td> <td>9449</td> <td>9107</td> </tr> </tbody> </table></p><p>Firefox 60のスコアはFirefox 52から1割アップし、Chrome 66を超えた。</p> </div> <div class="section"> <h5>WebGL</h5> <p><a href="https://developer.microsoft.com/en-us/microsoft-edge/testdrive/">Microsoft Edge TestDrive demos</a>から<a href="http://www.fishgl.com/">FishGL</a>をピックアップし、水槽内の魚の数を150匹に設定してテストを実行した。 このテストは、主にWebGLに関する処理性能を測定する。</p><p><table class="benchmark"> <thead> <tr> <th> </th> <th>Firefox 52</th> <th>Firefox 60</th> <th>Chrome 66</th> </tr> </thead> <tbody> <tr class="total"> <th>秒間フレーム数</th> <td>10 fps</td> <td>8 - 9 fps</td> <td>11 fps</td> </tr> </tbody> </table></p><p>ほとんど差がつかなかったが、Firefox 60のフレームレートが若干落ち込んでいるのは気になるところだ。</p><p>次に、<a href="https://files.unity3d.com/jonas/benchmark2015/">Unity WebGL Benchmarks</a> 2015年版での結果を見てみよう。このベンチマークは、Unityの開発したグラフィックスエンジンが一定時間内にどの程度のタスクを処理できるかをテストするものだ。<a href="https://blogs.unity3d.com/jp/2015/12/15/updated-webgl-benchmark-results/">Unity Blogの記事</a>によれば、Unity 5.3がベースになっているという。</p><p><table class="benchmark"> <thead> <tr> <th> </th> <th>Firefox 52</th> <th>Firefox 60</th> <th>Chrome 66</th> </tr> </thead> <tbody> <tr class="total"> <th>Overall Score</th> <td>44228</td> <td>55864</td> <td>50612</td> </tr> </tbody> </table></p><p>CanvasMark 2013と似たような傾向にあるが、こちらはFirefox 60のスコアがFirefox 52比で26%アップと伸びが大きい。</p> </div> <div class="section"> <h5>総合</h5> <p><a href="http://browserbench.org/MotionMark/">MotionMark</a> 1.0は、WebKitチームが提供するベンチマーク・スイートであり、複雑なシーンを目標フレームレートでアニメーションさせる能力を測定する。描画処理を中心とするものの、その他の能力も問われる重いテストである。画面サイズがMedium(900 x 600)の場合の結果は、以下のようになった。</p><p><table class="benchmark"> <thead> <tr> <th> </th> <th>Firefox 52</th> <th>Firefox 60</th> <th>Chrome 66</th> </tr> </thead> <tbody> <tr class="total"> <th>Score</th> <td>97.20 ± 6.73%</td> <td>109.28 ± 4.04%</td> <td>85.75 ± 19.13%</td> </tr> <tr> <th>Multiply</th> <td>118.75 ± 2.18%</td> <td>85.78 ± 3.54%</td> <td>222.35 ± 6.36%</td> </tr> <tr> <th>Canvas Arcs</th> <td>697.07 ± 2.56%</td> <td>802.59 ± 2.72%</td> <td>284.88 ± 1.78%</td> </tr> <tr> <th>Leaves</th> <td>141.80 ± 2.04%</td> <td>183.82 ± 2.24%</td> <td>283.17 ± 24.88%</td> </tr> <tr> <th>Paths</th> <td>2281.46 ± 2.46%</td> <td>2467.31 ± 3.62%</td> <td>820.63 ± 1.85%</td> </tr> <tr> <th>Canvas Lines</th> <td>1708.67 ± 2.36%</td> <td>2037.31 ± 1.77%</td> <td>4288.82 ± 1.74%</td> </tr> <tr> <th>Focus</th> <td>6.21 ± 4.04%</td> <td>8.93 ± 3.41%</td> <td>39.00 ± 5.13%</td> </tr> <tr> <th>Images</th> <td>13.56 ± 2.90%</td> <td>16.61 ± 2.71%</td> <td>25.46 ± 6.52%</td> </tr> <tr> <th>Design</th> <td>6.00 ± 33.33%</td> <td>7.48 ± 14.33%</td> <td>2.00 ± 100.00%</td> </tr> <tr> <th>Suits</th> <td>33.47 ± 3.31%</td> <td>31.50 ± 6.11%</td> <td>2.00 ± 50.00%</td> </tr> </tbody> </table></p><p>Firefox 60は、おおむねFirefox 52を上回る成績を収めている。グラフィックス関連の性能が、負荷のかかる状態で1割から2割程度アップしているのは間違いなさそうだ。これに対し、Chrome 66は今ひとつである。</p> </div> </div> <div class="section"> <h4>JavaScript/DOM処理</h4> <p><a href="http://browserbench.org/Speedometer2.0/" title="Speedometer 2.0">Speedometer</a> 2.0は、WebKitチームが提供するベンチマーク・スイートで、さまざまな手法によりDOM APIを酷使し、Webアプリの応答性をテストする。<a href="https://webkit.org/blog/8063/speedometer-2-0-a-benchmark-for-modern-web-app-responsiveness/" title="Speedometer 2.0: A Benchmark for Modern Web App Responsiveness | WebKit">バージョン2.0</a>では最新のJavaScriptフレームワークや言語仕様をサポートしたほか、スコアの算出方法も変更した。</p><p>GoogleのV8チームは<a href="https://v8project.blogspot.com/2017/04/retiring-octane.html" title="V8 JavaScript Engine: Retiring Octane">Octaneベンチマークを引退させて</a>、Speedometer 2.0の<a href="https://v8project.blogspot.com/2018/01/speedometer-2.html" title="V8 JavaScript Engine: Chrome welcomes Speedometer 2.0!">開発に参加</a>しており、実環境のパフォーマンスを反映したスコアが出ると太鼓判を押している。MozillaもFirefox Quantumのリリースにあたり、Quantum Flowプロジェクトにおいてこのスコアを<a href="https://ehsanakhgari.org/blog/2017-08-11/quantum-flow-engineering-newsletter-19" title="Quantum Flow Engineering Newsletter #19">重視した</a>。</p><p><table class="benchmark"> <thead> <tr> <th> </th> <th>Firefox 52</th> <th>Firefox 60</th> <th>Chrome 66</th> </tr> </thead> <tbody> <tr class="total"> <th>Runs / Minute</th> <td>24.4 ± 0.41</td> <td>46.7 ± 0.87</td> <td>57.6 ± 0.64</td> </tr> </tbody> </table></p><p>Firefox 60はFirefox 52の倍近いスコアを叩き出しており、Quantum Flowの成果が十分に認められる。それでもChrome 66には及ばないが、差を縮めていくことは可能だろう。</p><p><a href="http://browserbench.org/JetStream/">JetStream</a> 1.1は、WebKitチームが提供するベンチマーク・スイートで、SunSpider 1.0.2やOctane 2.0からも一部のベンチマークを取り入れ、スループットとレイテンシを計測する。</p><p><table class="benchmark"> <thead> <tr> <th> </th> <th>Firefox 52</th> <th>Firefox 60</th> <th>Chrome 66</th> </tr> </thead> <tbody> <tr class="total"> <th>Score</th> <td>123.48 ± 31.101</td> <td>134.95 ± 11.652</td> <td>127.95 ± 3.0543</td> </tr> </tbody> </table></p><p>Firefox 60がChrome 66を上回る最高のスコアを示した。</p><p>新たに加わった<a href="http://browserbench.org/ARES-6/index.html" title="ARES-6 1.0.1">ARES-6</a> 1.0.1は、WebKitチームが提供するベンチマーク・スイートで、JavaScriptの最新機能に焦点を当てて、その処理時間を計測する。起動が高速かつ処理が滑らかであれば、良い結果が出るように設計されており、結果のばらつきの大きさもスコアに反映される。</p><p><table class="benchmark"> <thead> <tr> <th> </th> <th>Firefox 52</th> <th>Firefox 60</th> <th>Chrome 66</th> </tr> </thead> <tbody> <tr class="total"> <th>Overall</th> <td>163.88 ± 2.35ms</td> <td>93.66 ± 2.83ms</td> <td>33.55 ± 0.50ms</td> </tr> </tbody> </table></p><p>Speedometer 2.0の場合と同様に、Firefox 60は大きな進歩を見せているのだが、いかんせんChrome 66が強い。</p><p>新たに加わった<a href="https://v8.github.io/web-tooling-benchmark/" title="Web Tooling Benchmark v0.4.0">Web Tooling Benchmark</a> v0.4.0は、GoogleのV8チームが提供するベンチマーク・スイートで、Web開発用のツールを動作させた場合のパフォーマンスを計測する。</p><p><table class="benchmark"> <thead> <tr> <th> </th> <th>Firefox 52</th> <th>Firefox 60</th> <th>Chrome 66</th> </tr> </thead> <tbody> <tr class="total"> <th>Runs/Sec</th> <td>2.33</td> <td>3.57</td> <td>6.75</td> </tr> </tbody> </table></p><p>ここでも、Firefox 60が5割以上の改善を示す一方、Chrome 66が強さを見せつけた。</p> </div> <div class="section"> <h4>asm.js</h4> <p>Emscriptenプロジェクトの一環として公開されているベンチマーク・スイート<a href="https://kripken.github.io/Massive/">MASSIVE</a> v1.2を走らせて、asm.jsの処理性能を見る。このベンチマークは大規模なasm.jsコードに特化しており、Poppler、SQLite、LuaとBox2Dのコードをベースに、スループットだけでなく、読み込み時間や読み込み中の応答性、パフォーマンスの一貫性なども計測対象とする。</p><p><table class="benchmark"> <thead> <tr> <th> </th> <th>Firefox 52</th> <th>Firefox 60</th> <th>Chrome 66</th> </tr> </thead> <tbody> <tr class="total"> <th>Score</th> <td>3911</td> <td>N/A</td> <td>1667</td> </tr> </tbody> </table></p><p>Firefox 60はハング状態となったためスコアを計測できなかった。Chromeはasm.jsの処理に関しては力を入れていないようだ。</p> </div> <div class="section"> <h4>総合的なベンチマーク・スイート</h4> <div class="section"> <h5>Basemark Web</h5> <p><a href="https://web.basemark.com/">Basemark Web</a> 3.0は、フィンランドのBasemark社が提供する総合ベンチマークで、最新のWeb標準と機能を用いて実環境のパフォーマンスを計測できるというのがセールスポイント。以下はConformanceがオン、Batteryがオフという初期設定で実行させた結果だ。</p><p><table class="benchmark"> <thead> <tr> <th> </th> <th>Firefox 52</th> <th>Firefox 60</th> <th>Chrome 66</th> </tr> </thead> <tbody> <tr class="total"> <th>Score</th> <td>270.09</td> <td>185.86</td> <td>293.43</td> </tr> </tbody> </table></p><p>Firefox 52がChrome 66に迫るスコアだったのに、Firefox 60になって大幅に落ち込むという謎の結果に。MASSIVEと同じく、バグのためどこか一部の処理が足を引っ張っているのかもしれない。</p> </div> <div class="section"> <h5>RoboHornet</h5> <p><a href="http://www.robohornet.org/">RoboHornet</a> RH-A1は、Benchmark.jsベースの総合ベンチマークで、α版だが完成度は高い(<a href="https://github.com/robohornet/robohornet/wiki/FAQ">FAQ</a>)。ここでは、標準的なCore Suiteを選んで計測した。</p><p><table class="benchmark"> <thead> <tr> <th> </th> <th>Firefox 52</th> <th>Firefox 60</th> <th>Chrome 66</th> </tr> </thead> <tbody> <tr class="total"> <th>RoboHornet index</th> <td>92.45</td> <td>106.22</td> <td>143.88</td> </tr> <tr> <th>Add Rows to Table</th> <td>5.48</td> <td>8.00</td> <td>9.49</td> </tr> <tr> <th>Add Columns to Table</th> <td>2.63</td> <td>4.85</td> <td>4.35</td> </tr> <tr> <th>Descendant Selector</th> <td>22.67</td> <td>23.91</td> <td>10.03</td> </tr> <tr> <th>2D Canvas toDataURL</th> <td>4.42</td> <td>4.76</td> <td>19.57</td> </tr> <tr> <th>2D Canvas clearRect</th> <td>5.70</td> <td>5.81</td> <td>11.76</td> </tr> <tr> <th>innerHTML Table</th> <td>2.87</td> <td>5.11</td> <td>2.96</td> </tr> <tr> <th>Table scrolling</th> <td>4.56</td> <td>6.56</td> <td>3.18</td> </tr> <tr> <th>Resize columns</th> <td>5.31</td> <td>8.05</td> <td>21.74</td> </tr> <tr> <th>Object Scope Access</th> <td>3.13</td> <td>3.06</td> <td>2.33</td> </tr> <tr> <th>ES5 Property Accessors</th> <td>11.85</td> <td>6.54</td> <td>6.77</td> </tr> <tr> <th>Argument instantiation</th> <td>1.81</td> <td>10.11</td> <td>10.31</td> </tr> <tr> <th>Animated GIFS</th> <td>0.80</td> <td>1.04</td> <td>0.31</td> </tr> <tr> <th>offsetHeight triggers reflow</th> <td>2.41</td> <td>3.80</td> <td>7.30</td> </tr> <tr> <th>DOM Range API</th> <td>4.88</td> <td>4.19</td> <td>5.18</td> </tr> <tr> <th>Write to localStorage</th> <td>8.51</td> <td>5.08</td> <td>13.71</td> </tr> <tr> <th>Read from localStorage</th> <td>5.41</td> <td>5.35</td> <td>14.91</td> </tr> </tbody> </table></p><p>ほとんどのテストでFirefox 60はスコアを伸ばし、総合的に15%程度の改善を見せている。ただ、Chrome 66との差はなお大きい。</p> </div> <div class="section"> <h5>WebXPRT</h5> <p><a href="http://www.principledtechnologies.com/benchmarkxprt/webxprt/">WebXPRT</a> 3 v2.93は、米Principled Technologies社が提供するWebベンチマークである。オフィスワーカー向けWebアプリを念頭に置いたらしき6つのタスクを、繰り返し7回実行することで、精度の高い判定を行う。タスクはWebXPRT 2015から一部変更されているようだ。以下の表で、総合スコアは数値が大きいほうがよいのに対し、個別の項目は処理に要する時間(ミリ秒)を示しており、数値が小さい方がよい。</p><p><table class="benchmark"> <thead> <tr> <th> </th> <th>Firefox 52</th> <th>Firefox 60</th> <th>Chrome 66</th> </tr> </thead> <tbody> <tr class="total"> <th>Score</th> <td>134</td> <td>167</td> <td>137</td> </tr> <tr> <th>Photo Enhancement</th> <td>481 ms</td> <td>373 ms</td> <td>347 ms</td> </tr> <tr> <th>Organize Album using AI</th> <td>2523 ms</td> <td>2370 ms</td> <td>2698 ms</td> </tr> <tr> <th>Stock Option Pricing</th> <td>341 ms</td> <td>262 ms</td> <td>290 ms</td> </tr> <tr> <th>Encrypt Notes and OCR Scan</th> <td>2059 ms</td> <td>1700 ms</td> <td>3279 ms</td> </tr> <tr> <th>Sales Graphs</th> <td>681 ms</td> <td>611 ms</td> <td>652 ms</td> </tr> <tr> <th>Online Homework</th> <td>3754 ms</td> <td>2480 ms</td> <td>3318 ms</td> </tr> </tbody> </table></p><p>Firefox 60がFirefox 52比で約25%のスコアアップを達成し、Chrome 66を抑えてトップに立った。</p> </div> </div> <div class="section"> <h4>総合評価</h4> <p>一部のテストで不自然な結果が確認されたものの、Firefox 60はFirefox 52を圧倒しており、パフォーマンスが大幅に向上したことは疑う余地がない。これには、64bit化、e10s-multi(Quantum Compositor〔GPUプロセス〕を含む)の全面的導入、Quantum Flowにおける地道な改良の積み重ね、Quantum CSS(Stylo)の実装など、複合的な要因が作用しているとみられる。今回は適切なテストがなく見送ったが、WebAssemblyの処理性能まで含めていれば、さらに差がついたはずだ。</p><p>MozillaはSpeedometer 2.0のスコアを根拠として、1年間で2倍の速さになったとアピールしているが、実環境における複雑なタスクを基準にすると、15%から25%の改善といったところが適切ではないか。一見すると小さな数字に見えるかもしれないが、PC性能の伸びが鈍化する一方、Webアプリが重量化している近年の状況からすると、下手をすればPCを買い換えたくらいの違いがある。</p><p>Firefox 60とChrome 66を比較した場合も、相対的に古いベンチマークでは差がつきにくく、グラフィックス関連ではFirefoxのほうが良いパフォーマンスを示すケースもある。また、WebXPRT 3のように実環境に近いテストでも、FirefoxはChromeに勝る実力を示した。もっとも、DOM関連の処理の速さや安定性ではChromeに軍配が上がる。追いつくまでにはまだまだ時間がかかるだろう。</p><p>消費メモリに関しても、Firefoxは多プロセス化が進んでメモリを喰うようになったのに対し、ChromeはJavaScriptエンジンの改良によって効率的なメモリ利用を実現するに至っており、MozillaがアピールするほどFirefoxが省メモリというわけではなさそうだ。ただ、昔と違ってメモリを消費してもFirefoxの動作は重くなりにくい。デスクトップ環境において消費メモリを競う意義は小さくなっているのかもしれない。</p><p>次のESRは、Firefox 66がベースになると予想される。MozillaがFirefox 59ではなく60をもってESRとしたのは、Policy Engineという企業向け機能を開発するためだったが、毎年11月ころに大きな開発成果を投入するという最近の開発パターンと照らし合わせると、3月ころに新ESRを出さないと開発に支障が出かねない。ESRが出るまでは互換性に配慮して大きな変更を加えづらいが、大きな変更ほど長いテスト期間を要するためだ。おそらくFirefox 66では、開発が遅れているQuantum Renderが初期設定で有効化されているだろう。Quantum Flowのようなプロジェクトが再度行われて、その成果も投入されているはずだ。今回、FirefoxはChromeを視界に捉えるところまで来たが、次回は背中が見えていることを期待したい。</p> </div><div class="footnote"> <p class="footnote"><a href="#fn-6369ca97" name="f-6369ca97" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text"><a href="http://www.erahm.org/2017/03/10/are-they-slim-yet-round-2/" title="Are they slim yet, round 2">Are they slim yet, round 2</a>参照</span></p> <p class="footnote"><a href="#fn-ede8cba5" name="f-ede8cba5" class="footnote-number">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text">Firefoxとの単純比較は困難だが、この方法であればChromeのメモリ使用量が過大に出ることはないはず。</span></p> <p class="footnote"><a href="#fn-f6756e8b" name="f-f6756e8b" class="footnote-number">*3</a><span class="footnote-delimiter">:</span><span class="footnote-text"><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1188834">Bug 1188834</a>参照。javascript.options.compact_on_user_inactive_delayの値はその後も変わっていない。</span></p> </div> Rockridge Firefox 60以降でもMozilla Add-ons(AMO)上で拡張機能を動作させる裏技 hatenablog://entry/17391345971641486152 2018-05-04T22:22:58+09:00 2018-05-04T22:22:58+09:00 Firefox 57以降、初期設定のままだと拡張機能はMozilla Add-ons(AMO)などMozillaが運用するWebサイト上で動作しない。悪意ある拡張機能にMozillaの信用性を利用されないための措置だが、拡張機能の使い勝手は当然落ちる。マウスジェスチャが使えないだけでなく、たとえば右クリック+マウスホイール回転でタブを切り替えていく場合、該当するWebサイトがあると、そこで切り替えが止まってしまうのだ。そこで、How to enable Firefox WebExtensions on Mozilla websites - gHacks Tech Newsなどで紹介されているテ… <p>Firefox 57以降、初期設定のままだと拡張機能はMozilla Add-ons(AMO)などMozillaが運用するWebサイト上で動作しない。悪意ある拡張機能にMozillaの信用性を利用されないための措置だが、拡張機能の使い勝手は当然落ちる。マウスジェスチャが使えないだけでなく、たとえば右クリック+マウスホイール回転でタブを切り替えていく場合、該当するWebサイトがあると、そこで切り替えが止まってしまうのだ。</p><p>そこで、<a href="https://www.ghacks.net/2017/10/27/how-to-enable-firefox-webextensions-on-mozilla-websites/" title="How to enable Firefox WebExtensions on Mozilla websites - gHacks Tech News">How to enable Firefox WebExtensions on Mozilla websites - gHacks Tech News</a>などで紹介されているテクニックを利用している人もいるだろう(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1384330" title="1384330 - Don't expose window.navigator.mozAddonManager data when privacy.resistFingerprinting=true">Bug 1384330</a>参照)。方法をおさらいしておくと、1.アドレスバーに"about:config"と打ち込んでページを開き、「動作保証対象外になります!」という警告が出たときは、「危険性を承知の上で使用する」をクリックして先へ進む。2. <strong>privacy.resistFingerprinting.block_mozAddonManager</strong>の設定を新規作成し、真偽値をtrueにする。</p><p>だが、Firefox 60以降、このテクニックだけでは不十分になった(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1445893" title="1445893 - privacy.resistFingerprinting.block_mozAddonManager stopped working v60.0b3">Bug 1445893</a>参照)。拡張機能の動作を制限するドメインの仕組みが<a href="https://hg.mozilla.org/mozilla-central/rev/39e131181d44" title="mozilla-central: changeset 407481:39e131181d44">新たに追加された</a>ためだ。このドメイン一覧からAMOを取り除くという一捻りが必要となる。</p><p>about:configの画面で検索ボックスに<strong>extensions.webextensions.restrictedDomains</strong>の設定名を入力し、表示された設定をダブルクリックしてみよう。すると「文字列を入力してください」というダイアログが表示されるので、&quot;addons.mozilla.org,&quot;を消去し、OKをクリックする。これで再びAMO上で拡張機能が動作するようになる。ただし、<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1310082#c32" title="1310082 - WebExtension content script not working on mozilla.org sites">公式にサポートされた方法ではない</a>ので、将来的に通用しなくなる可能性があることに注意してほしい。</p> Rockridge Firefox Quantumのイースター・エッグ hatenablog://entry/17391345971640089730 2018-04-30T21:20:05+09:00 2018-04-30T21:20:05+09:00 今さらではあるが、Firefox 57以降を対象としたイースター・エッグの存在が判明したので紹介しておきたい(Bug 1405009)。Firefox Quantumの新UI(Photon)では、オプション画面に検索機能が付いており、検索文字列と一致する項目をピックアップしてくれるのだが、一致する項目がない場合は、その旨のメッセージとともにモノトーンの画像が表示される。左:オプション画面の検索機能 右:一致する項目がなかった場合ところが、検索文字列に「🔥🦊」の絵文字(つまり火と狐)を入力すると、専用のカラー画像が表示されるのだ。画像に出てくるキャラクターたちはPhoton UIの各所で用いられ… <p>今さらではあるが、Firefox 57以降を対象としたイースター・エッグの存在が判明したので紹介しておきたい(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1405009" title="1405009 - Failed search in prefs could do something different">Bug 1405009</a>)。</p><p>Firefox Quantumの新UI(Photon)では、オプション画面に検索機能が付いており、検索文字列と一致する項目をピックアップしてくれるのだが、一致する項目がない場合は、その旨のメッセージとともにモノトーンの画像が表示される。</p><p><figure class="figure-image figure-image-fotolife" title="左:オプション画面の検索機能 右:一致する項目がなかった場合"><div class="images-row mceNonEditable"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180430/20180430210051.png" alt="f:id:Rockridge:20180430210051p:plain" title="f:id:Rockridge:20180430210051p:plain" class="hatena-fotolife" itemprop="image"></span><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180430/20180430210107.png" alt="f:id:Rockridge:20180430210107p:plain" title="f:id:Rockridge:20180430210107p:plain" class="hatena-fotolife" itemprop="image"></span></div><figcaption>左:オプション画面の検索機能 右:一致する項目がなかった場合</figcaption></figure></p><p>ところが、検索文字列に「🔥🦊」の絵文字(つまり火と狐)を入力すると、専用のカラー画像が表示されるのだ。画像に出てくるキャラクターたちはPhoton UIの各所で用いられているが、ふだんはモノトーンで描かれているものが、色鮮やかに、しかも集合写真風に並ぶとそれなりに味わいがある。</p><p><figure class="figure-image figure-image-fotolife" title="イースター・エッグの画像"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180430/20180430210432.png" alt="f:id:Rockridge:20180430210432p:plain" title="f:id:Rockridge:20180430210432p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>イースター・エッグの画像</figcaption></figure></p><p><a href="https://rockridge.hatenablog.com/entry/20140429/1398775185" title="Australisのイースター・エッグその他 - Mozilla Flux">Australisのとき</a>は画像が動いていたので、それと比べると今回のイースター・エッグは慎ましいが、制作者の遊び心が感じられてよい。</p> Rockridge Firefox QuantumのOff Main Thread Painting(OMTP)とRetained Display Listsについて hatenablog://entry/8599973812341686404 2018-01-28T22:49:25+09:00 2018-01-28T22:49:25+09:00 Windows版Firefox 58でOMTPが有効化 Firefox 58ではWindows版に限って、以前紹介したOff Main Thread Painting(OMTP)と呼ばれる機能が有効化されている(Bug 1403935)。このOMTPに対し、画像処理に関するものだという誤解が一部にあるようなので、その誤解を解いておきたい。まずはGeckoのグラフィックス・パイプラインのおさらいから。Geckoでは、DOMツリー → フレームツリー → ディスプレイリスト → レイヤーツリーの順に処理が流れていき、最後にcompositorがレイヤーツリーを合成する。今回取り上げるのは、「ディス… <div class="section"> <h4>Windows版Firefox 58でOMTPが有効化</h4> <p>Firefox 58ではWindows版に限って、<a href="http://rockridge.hatenablog.com/entry/2017/12/04/003442" title="Firefox 58以降も続く高速化と応答性向上 2018年もパフォーマンス2倍が目標 - Mozilla Flux">以前紹介した</a>Off Main Thread Painting(OMTP)と呼ばれる機能が有効化されている(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1403935" title="1403935 - Enable OMTP by Default on Windows nightly">Bug 1403935</a>)。このOMTPに対し、画像処理に関するものだという誤解が<a href="http://www.itmedia.co.jp/news/articles/1801/24/news087.html" title="「Firefox Quantum」(バージョン58)公開 さらに高速化、多数の脆弱性修正 - ITmedia NEWS">一部にある</a>ようなので、その誤解を解いておきたい。</p><p>まずはGeckoのグラフィックス・パイプラインのおさらいから。Geckoでは、DOMツリー → フレームツリー → ディスプレイリスト → レイヤーツリーの順に処理が流れていき、最後にcompositorがレイヤーツリーを合成する。今回取り上げるのは、「ディスプレイリスト → レイヤーツリー」の処理の部分だ。</p><p><figure class="figure-image figure-image-fotolife" title="Geckoのグラフィックス・パイプライン"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171204/20171204000145.png" alt="f:id:Rockridge:20171204000145p:plain" title="f:id:Rockridge:20171204000145p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>Geckoのグラフィックス・パイプライン</figcaption></figure></p><p><a href="https://mozillagfx.wordpress.com/2017/12/05/off-main-thread-painting/" title="Off-Main-Thread Painting – Mozilla Gfx Team Blog">Off-Main-Thread Painting – Mozilla Gfx Team Blog</a>によれば、Geckoの描画処理は、合成(Compositing)のフェーズを別にすると3段階に分けることができる。具体的には、1)ディスプレイリストの構築、2)レイヤーの割り当て、3)ラスタライゼーションである。</p><p>1)ディスプレイリストの構築では、ページ内の視覚的要素を収集し、ディスプレイアイテムと呼ばれる高水準プリミティブを生成する。2)レイヤーの割り当てでは、ディスプレイアイテムをグループにまとめてPaintedレイヤーと呼ばれる複数のレイヤーに割り当てる。3)ラスタライゼーションでは、レイヤーに割り当てられたディスプレイアイテムが実際に描画される。</p><p>これまでは上記3段階がすべてメインスレッドにおいて処理されてきた。これに対し、OMTPは3段階目のラスタライゼーションを別スレッドで非同期に処理する。この別スレッドは、ペイントスレッドと呼ばれる。</p><p><figure class="figure-image figure-image-fotolife" title="ラスタライゼーションの非同期化"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180128/20180128204314.png" alt="f:id:Rockridge:20180128204314p:plain" title="f:id:Rockridge:20180128204314p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>ラスタライゼーションの非同期化</figcaption></figure></p><p>メインスレッドはラスタライゼーションの手前で解放され、次の処理に移ることができる。また、ペイントスレッドはメインスレッドと並行してラスタライゼーション処理に集中することができる。この流れ作業によって、スレッド間での処理の受け渡しが発生するものの、全体としては、互いに前の処理を待つ時間を短縮することが可能になるわけだ。</p><p><figure class="figure-image figure-image-fotolife" title="非同期化のメリット"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180128/20180128204257.png" alt="f:id:Rockridge:20180128204257p:plain" title="f:id:Rockridge:20180128204257p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>非同期化による流れ作業の実現</figcaption></figure></p><p>OMTPが力を発揮するのは、メインスレッドの処理に余裕がない場合である。たとえば、重いJavaScriptを処理しながらグラフィックスの処理も行う場面では、ラスタライゼーションをペイントスレッドが担うことで、処理落ちを防ぐことができる。そうした場面でOMTPを有効化すると、Windows版で30%程度フレームレート(FPS)が向上することが、Mozillaの開発者の調査結果から明らかになっている。</p><p><figure class="figure-image figure-image-fotolife" title="OMTPによるFPSの向上"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180128/20180128204241.png" alt="f:id:Rockridge:20180128204241p:plain" title="f:id:Rockridge:20180128204241p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>OMTPによるFPSの向上</figcaption></figure></p> </div> <div class="section"> <h4>Retained Display Listsでディスプレイリストの構築コストに対処</h4> <p>Firefox 59以降のNightlyチャンネルでは、Retained Display Listsと呼ばれる機能が有効化されている(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1416055" title="1416055 - Enable retained display lists on Nightly">Bug 1416055</a>)。この機能は前記の1)ディスプレイリストの構築に関わるもの。Geckoの描画処理において、ディスプレイリストの構築は処理時間の40%以上という高い割合を占める。Retained Display Listsは、リストの構築コストを大幅に削減するための技法だ。</p><p><a href="https://mozillagfx.wordpress.com/2018/01/09/retained-display-lists/" title="Retained Display Lists – Mozilla Gfx Team Blog">Retained Display Lists – Mozilla Gfx Team Blog</a>によれば、これまで、スクリーンの表示内容に変更が生じたときは、ディスプレイリストを一から構築し直していた。他方、Retained Display Listsの導入後は、これを原則として維持し、表示内容が変更された部分についてだけ新しいリストを構築して、新リストを旧リストに統合する。通常、表示内容が変更されるのは画面内の一部にとどまるので、新リストは比較的小さなもので済む可能性が高い。一から構築し直す場合と比べて処理時間を短縮できるわけだ。</p><p>Mozillaの開発者がFirefox 58 Betaのユーザーを対象にA/Bテストを実施しており、Retained Display Listsを有効化すると、16ミリ秒を超える「遅い」描画処理を30%近く削減できるという結果が出ている。しかも、Firefox 59には表示内容に全く変更がなければリストを維持し続ける機能(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1419021" title="1419021 - Retain display list when there are no changes">Bug 1419021</a>)が追加実装されたため、現在ではさらに効果が大きくなっているとみられる。</p><p><figure class="figure-image figure-image-fotolife" title="Retained Display Listsの効果"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180128/20180128204323.png" alt="f:id:Rockridge:20180128204323p:plain" title="f:id:Rockridge:20180128204323p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>Retained Display Listsの効果</figcaption></figure></p><p>OMTPのように「重いJavaScriptを処理しながら」といった制約がない分、Retained Display Listsのメリットは大きいが、表示内容に変更が生じた分だけディスプレイリストを構築する仕組みは複雑であり、完成までに時間がかかっている。現状ではFirefox 59リリース版への投入は難しく、Firefox 60で有効化されることになりそうだ。</p> </div> Rockridge マウスホイールでページをスクロールする際の小技(Firefox 58以降) hatenablog://entry/8599973812340367068 2018-01-24T00:43:55+09:00 2018-07-22T21:15:22+09:00 Firefox 58がリリースされ、既に手動アップデートが可能な状況になっている。パフォーマンスの向上については別記事を参照していただくとして、ここではマウスホイールでページをスクロールする際の小技を2つ取り上げたい。どちらもFirefox 58で実装された機能だ。1つ目は、スムーズスクロールの挙動を変更するというもの(Bug 1402498)。about:configのページでgeneral.smoothScroll.msdPhysics.enabledをtrueに変更すると有効化される。加速・減速のシミュレーションにcubic-bezierを用いる現行方式とは異なり、新方式ではMass-s… <p>Firefox 58が<a href="https://www.mozilla.org/en-US/firefox/58.0/releasenotes/" title="Firefox — Notes (58.0) — Mozilla">リリースされ</a>、既に手動アップデートが可能な状況になっている。パフォーマンスの向上については別記事を参照していただくとして、ここではマウスホイールでページをスクロールする際の小技を2つ取り上げたい。どちらもFirefox 58で実装された機能だ。</p><p>1つ目は、スムーズスクロールの挙動を変更するというもの(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1402498" title="1402498 - Add an alternative smooth scroll physics implementation based on a Mass-Spring-Damper">Bug 1402498</a>)。about:configのページで<strong>general.smoothScroll.msdPhysics.enabled</strong>をtrueに変更すると有効化される。加速・減速のシミュレーションにcubic-bezierを用いる現行方式とは異なり、新方式では<a href="https://en.wikipedia.org/wiki/Mass-spring-damper_model" title="Mass-spring-damper model - Wikipedia">Mass-spring-damper</a>を用いるのだという。実際にマウスホイールを回してページをスクロールさせてみると、現行方式よりも加速の度合いが大きく、より少ないホイール回転で終端に到達する。新方式を好むユーザーも少なくないのでは、と思う。</p><p>2つ目は、Shiftキーを押しながらマウスホイールを回すと横スクロールになるというもの(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=143038" title="143038 - Horizontal Scrolling with Mouse wheel+ modifier key">Bug 143038</a>)。macOS版では<a href="https://groups.google.com/forum/#!topic/mozilla.dev.platform/QpiSeUt86WM" title="Intent to ship: New default action, horizontal scroll, of wheel with Shift key (except Firefox for macOS) - Google グループ">OSの挙動に合わせて最初からそうなっている</a>ようだが、Windows版などでは旧式の拡張機能を使わないと実現できなかった。旧式拡張機能の廃止に伴い、16年前に登録されたバグが修正され、デスクトップ版における方式が統一された。</p> Rockridge Firefox 58でWebAssemblyの起動を大幅に高速化 hatenablog://entry/8599973812339669317 2018-01-21T18:59:10+09:00 2018-01-22T08:31:34+09:00 WebAssemblyは既にメジャーなブラウザすべてでサポートされており、その用途も、たとえばGoogle Earthが移植されるなど、ゲームに限られなくなってきている。もっとも、これまではダウンロード後のコンパイルに時間がかかるという問題があった。Firefox 58では2つの新技術でこの問題に対処し、WebAssemblyアプリケーションの起動を大幅に高速化する。Making WebAssembly even faster: Firefox’s new streaming and tiering compiler – Mozilla Hacksによれば、1つ目の新技術はストリーミング(St… <p>WebAssemblyは既に<a href="https://blog.mozilla.org/blog/2017/11/13/webassembly-in-browsers/" title="WebAssembly support now shipping in all major browsers - The Mozilla Blog">メジャーなブラウザすべて</a>でサポートされており、その用途も、たとえば<a href="https://medium.com/google-earth/earth-on-web-the-road-to-cross-browser-7338e0f46278" title="Earth on Web: The road to cross browser – Google Earth and Earth Engine – Medium">Google Earth</a>が移植されるなど、ゲームに限られなくなってきている。もっとも、これまではダウンロード後の<a href="http://nmi.jp/2017-12-03-Profiling-of-huge-wasm" title="巨大 WebAssembly ファイルのコンパイル時間">コンパイルに時間がかかる</a>という問題があった。Firefox 58では2つの新技術でこの問題に対処し、WebAssemblyアプリケーションの起動を大幅に高速化する。</p><p><a href="https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-firefoxs-new-streaming-and-tiering-compiler/" title="Making WebAssembly even faster: Firefox’s new streaming and tiering compiler – Mozilla Hacks – the Web developer blog">Making WebAssembly even faster: Firefox’s new streaming and tiering compiler – Mozilla Hacks</a>によれば、1つ目の新技術はストリーミング(Streaming)という。ダウンロードの完了を待たずにコンパイルを開始するもので、この技術はWebAssemblyのファイル形式と相性がいい。単一のファイルのうち、最初にコード部分がダウンロードされるため、これをコンパイルしながら、データ部分のダウンロードの完了を待つことができるのだ。</p><p><figure class="figure-image figure-image-fotolife" title="WebAssemblyファイルの構造"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180121/20180121174236.png" alt="f:id:Rockridge:20180121174236p:plain:w400" title="f:id:Rockridge:20180121174236p:plain:w400" class="hatena-fotolife" style="width:400px" itemprop="image"></span><figcaption>WebAssemblyファイルの構造</figcaption></figure></p><p>もう1つの技術は、段階的(tiered)なコンパイルである。動作は高速だが生成されるコードの最適化が弱いコンパイラと、動作は低速だが生成されるコードの最適化が強力なコンパイラを用意しておき、初めに前者のコンパイラがメインスレッドでWebAssemblyファイルのコンパイルを行う。コードの実行が始まったところで、これと並行して後者のコンパイラが別スレッドで動き出し、コードのコピーに対し最適化を施す。最適化が完了したコードは、メインスレッドのコードと置き換えられる仕組みだ(ホットスワップ)。</p><p><figure class="figure-image figure-image-fotolife" title="段階的なコンパイル"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20180121/20180121180415.png" alt="f:id:Rockridge:20180121180415p:plain:w600" title="f:id:Rockridge:20180121180415p:plain:w600" class="hatena-fotolife" style="width:600px" itemprop="image"></span><figcaption>WebAssemblyファイルの段階的なコンパイル</figcaption></figure></p><p>1段階目のコンパイラは、2段階目のそれよりも10倍から15倍も高速にコンパイルを行うことができる一方、生成されるコードの速度は2段階目のコンパイラと比較して、半分程度を確保している。この2段階のコンパイルはWebAssemblyのすべてのコードに対して適用されるが、それによってWebAssemblyの強みである処理速度を損なうことはない。</p><p>このように、Firefox 58では、1段階目のコンパイラがWebAssemblyファイルのダウンロード完了を待たずにコンパイルを開始し、実行中のコードは2段階目のコンパイラが最適化したコードに後で置き換えられるわけだ。では、実際にどの程度の威力を発揮するのだろうか。</p><p>GitHub上でMozillaの開発者が公開している<a href="https://lukewagner.github.io/test-tanks-compile-time/">ベンチマーク</a>を、Firefox 57.0.4(ビルド ID: 20180103231032)とFirefox 58 RC1(ビルド ID :20180115093319)の双方で走らせてみた。12.4MBのWebAssemblyファイルについて、<a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/instantiate" title="WebAssembly.instantiate() - JavaScript | MDN">WebAssembly.instantiate()</a>の所要時間を計測するもので、単位はミリ秒(ms)。例えばダウンロード完了からの所要時間が1000msだとすると、1秒あたり12.4MBのコードを処理できていることになる。ベンチマークでは、そのスループットも結果として表示される。5回計測した平均は、以下のとおり。</p><p><table class="benchmark"> <thead> <tr> <th> </th> <th>Firefox 57</th> <th>Firefox 58</th> </tr> </thead> <tbody> <tr> <th>所要時間</th> <td>2611.9 ms</td> <td>319.0 ms</td> </tr> <tr> <th>スループット</th> <td>4.8 MB/s</td> <td>38.9 MB/s</td> </tr> </tbody> </table></p><p><strong>Firefox 58のほうが約8.1倍も高速</strong>という結果になった。これだけ速ければ、実環境でも違いを体感できるはず。さらにそう遠くない将来、WebAssemblyのコンパイル結果はHTTPキャッシュに保存され、2回目以降の起動が加速される見通しだ。実行開始から一貫して速いと開発者に知れ渡れば、WebAssemblyアプリケーションの普及に弾みが付くことだろう。</p> Rockridge Firefoxのパスワードマネージャーを刷新するLockboxプロジェクトが本格始動中 hatenablog://entry/8599973812331235626 2017-12-29T22:38:50+09:00 2017-12-29T22:38:50+09:00 Firefoxにはパスワードマネージャー機能が搭載されており、Webサイトへのアクセスに利用するユーザー名とパスワードを安全に保存して、同じサイトに再びアクセスした際にそのアカウント情報を自動的に入力してくれる。このパスワードマネージャーの全面的な書き換えを目指すのがLockboxプロジェクトであり、既に拡張機能の形式で開発者向けα版の提供が開始されている。Lockbox α版のスタート画面今のところα版は、Firefox本体のパスワードマネージャーを置き換えるものの機能面ではかなり限定されており、ユーザーが自分でアカウント情報を登録したエントリーを作成せねばならない。だが、マスターパスワード… <p>Firefoxには<a href="https://support.mozilla.org/ja/kb/password-manager-remember-delete-change-and-import" title="Firefox のパスワードマネージャー | Firefox ヘルプ">パスワードマネージャー</a>機能が搭載されており、Webサイトへのアクセスに利用するユーザー名とパスワードを安全に保存して、同じサイトに再びアクセスした際にそのアカウント情報を自動的に入力してくれる。このパスワードマネージャーの全面的な書き換えを目指すのが<a href="https://github.com/mozilla-lockbox" title="Lockbox">Lockboxプロジェクト</a>であり、既に拡張機能の形式で<a href="https://mozilla-lockbox.github.io/lockbox-extension/" title="Introduction - Lockbox Extension">開発者向けα版</a>の提供が開始されている。</p><p><figure class="figure-image figure-image-fotolife" title="Lockbox"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171229/20171229214216.png" alt="f:id:Rockridge:20171229214216p:plain" title="f:id:Rockridge:20171229214216p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>Lockbox α版のスタート画面</figcaption></figure></p><p>今のところα版は、Firefox本体のパスワードマネージャーを置き換えるものの機能面ではかなり限定されており、ユーザーが自分でアカウント情報を登録したエントリーを作成せねばならない。だが、<a href="https://github.com/mozilla-lockbox/lockbox-extension/issues/209" title="Secure your Lockbox: FxA as master password and to allow sync · Issue #209 · mozilla-lockbox/lockbox-extension">マスターパスワードに代えて</a>Firefoxアカウントによる暗号化が可能になっている点は目新しい。<a href="https://mozilla-lockbox.github.io/lockbox-extension/faqs/" title="FAQs - Lockbox Extension">FAQ</a>によれば暗号化処理にAES256-GCMを、ハッシュ処理にHMAC SHA-256をそれぞれ利用しており、保存された情報は強力に保護されるそうだ。</p><p>今後、Lockboxが現行のパスワードマネージャーの機能を取り込んでいくのは当然として、さまざまな新機能についても検討されている。<a href="https://github.com/mozilla-lockbox/lockbox-extension/issues/161" title="Password Generation · Issue #161 · mozilla-lockbox/lockbox-extension">パスワードの生成</a>や<a href="https://github.com/mozilla-lockbox/lockbox-extension/issues/252" title="Export to .csv · Issue #252 · mozilla-lockbox/lockbox-extension">エクスポート</a>、LastPassなど<a href="https://github.com/mozilla-lockbox/lockbox-extension/issues/202" title="import sites from other password managers · Issue #202 · mozilla-lockbox/lockbox-extension">他のサービスからのインポート</a>は有用だろう。Webサイトで新規アカウントが作成されたことを検知して<a href="https://github.com/mozilla-lockbox/lockbox-extension/issues/313" title="URI detection in create new entry via doorhanger · Issue #313 · mozilla-lockbox/lockbox-extension">エントリーを自動で追加</a>してくれる機能も便利そうだ。モバイル向けに<a href="https://github.com/mozilla-lockbox/lockbox-extension/issues/272" title="Support fingerprint readers · Issue #272 · mozilla-lockbox/lockbox-extension">指紋認証をサポート</a>する話もある。</p><p>Lockboxのβ版は<a href="https://mozilla.invisionapp.com/share/MHEBCD4PK#/screens/264173109">Test Pilotで公開される</a>予定だ。ユーザーからのフィードバックを経て、Firefox本体に取り込まれることになるとみられる。パスワードマネージャーの刷新時期は不明だが、2018年11月にリリースされるFirefox 64がターゲットということは十分に考えられそうだ。また、モバイルアプリ版の開発や(拡張機能として)Firefox以外のブラウザへの展開も視野に入れているそうなので、Firefoxアカウントを普及させるためのツールとしての役割も期待されている可能性がある。</p> Rockridge 次のFirefox ESRはバージョン59ではなく60 その影響を探る hatenablog://entry/8599973812327464325 2017-12-17T22:36:04+09:00 2017-12-29T22:51:24+09:00 Firefox ESR(延長サポート版)は年に1回、メジャーアップデートが実施される。その時期には法則性があって、Firefoxのバージョン番号から10を引くと7の倍数になる。直近だとFirefox 52なわけだが、最初のESRがバージョン10からスタートしたため、こうした中途半端な数字になっている。本来であればFirefox 59が次のESRとなるはず。ところが、Firefox/EnterprisePolicies - MozillaWikiによれば、Firefox 60を次のESRとするという。言い換えると、次のESRのリリース時期が、2018年3月から5月へと延期されたわけだ。延期の背景… <p><a href="https://www.mozilla.jp/business/" title="法人向け情報 | Mozilla Japan コミュニティポータル">Firefox ESR(延長サポート版)</a>は年に1回、メジャーアップデートが実施される。その時期には法則性があって、Firefoxのバージョン番号から10を引くと7の倍数になる。直近だとFirefox 52なわけだが、最初のESRがバージョン10からスタートしたため、こうした中途半端な数字になっている。</p><p>本来であればFirefox 59が次のESRとなるはず。ところが、<a href="https://wiki.mozilla.org/Firefox/EnterprisePolicies" title="Firefox/EnterprisePolicies - MozillaWiki">Firefox/EnterprisePolicies - MozillaWiki</a>によれば、Firefox 60を次のESRとするという。言い換えると、次のESRのリリース時期が、2018年3月から5月へと延期されたわけだ。</p><p>延期の背景には、法人ユーザー向けに&quot;Policy Engine&quot;と呼ばれるFirefoxのカスタマイズ機能を提供する計画があるようだ。従来、こうしたカスタマイズはおおむね旧式拡張機能によってカバーされてきた。だが、Firefox Quantumで拡張機能のWebExtensions限定化が実施され、状況が大きく変わった。たとえば<a href="https://mike.kaply.com/2017/11/15/firefox-quantum-and-cck2/" title="Firefox Quantum and CCK2 | Mike's Musings">CCK2 Wizard</a>はFirefox ESR 52での利用が推奨され、<a href="http://www.clear-code.com/blog/2017/12/8.html" title="Firefox Quantum以降のglobalChrome.cssの移行について - ククログ(2017-12-08)">globalChrome.css</a>はuserChrome.css/userContent.cssへの移行を検討せねばならなくなっている。Mozilla公式のカスタマイズ機能が求められるゆえんだ。</p><p>Firefoxの新コンポーネントとなるPolicy Engineの開発に一定の期間を要するため、ESRのリリース時期がイレギュラーとなった。この理由を見るかぎり、おそらくリリース時期の変動は今回限りの措置だろう。Firefox ESR 60の次は、ESR 67ではなく66になるとみられる。</p><p>次期ESRの登場が後ろ倒しになった影響で、Firefox ESR 52系列のサポート期間は延びることになりそうだ。新ESRと旧ESRは2バージョンの間並行してリリースされ、これが移行の猶予期間になっている。猶予期間を削るわけにはいかないだろうから、新ESRのリリース時期を遅らせた分だけ、旧ESRつまりESR 52のサポートを長く続けざるをえないというわけだ。サポート終了が2018年8月下旬になるので、旧式アドオンを使うためESRチャンネルに乗り換えたユーザーや、Windows XP/Vista上のユーザーにとっては朗報と言える。</p><p>また、ThunderbirdもFirefox ESRと同じWebエンジン(Gecko)を使用しているので、メジャーバージョンアップの時期がずれてくるだろう。次期ThunderbirdはFirefoxと異なり<a href="https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_57" title="Thunderbird/Add-ons Guide 57 - MozillaWiki">旧式アドオンのサポートを続ける</a>一方で、アドオン側の対応が求められており、未対応のアドオンは<a href="http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/2017-December/000409.html" title="[Maildev] add-ons in thunderbird 59 - not compatible by default">初期設定で無効化される</a>。アドオン作者が開発に使える時間が増えれば、対応するアドオンが揃う可能性は高くなる。</p><p>ちなみに、Policy Engineはシステム管理者による利用が想定されているものの、ESRチャンネル以外でも有効化することは可能なようだ。カスタマイズ用の「ポリシー」は、一部機能の制限やブックマークの追加などが中心だが、初期設定でメニューバーを有効化するといったUIの調整についても議論されているという。仮にUIのカスタマイズが柔軟にできるようなら、部分的にuserChrome.cssを代替できるかもしれない。</p><p><em>(17/12/29追記)</em><br>本記事執筆後、<a href="https://forest.watch.impress.co.jp/docs/serial/yajiuma/1097742.html" title="次期「Firefox ESR」は「Firefox 60」ベースに ~現行版「Firefox ESR 52」は少し延命 - やじうまの杜 - 窓の杜">次期「Firefox ESR」は「Firefox 60」ベースに ~現行版「Firefox ESR 52」は少し延命 - 窓の杜</a>がこの話題を取り上げ、<a href="https://www.mozilla.org/en-US/firefox/organizations/" title="Firefox Extended Support Release for Your Organization, Business, Enterprise — Mozilla">Firefox ESRの英語ページ</a>の図がアップデートされて、Firefox 60を次のESRとする一方、ESR 52系列のサポートが52.9まで続く形になっていることを指摘した。また、米国時間の2017年12月21日にはMozillaから<a href="https://groups.google.com/d/topic/mozilla.dev.platform/VF7cEdlzRg0" title="Fwd: Announcing the next Extended Support Release of Firefox - ESR60 with policy engine - Google グループ">正式なアナウンス</a>も出ている。それによると、Firefox ESR 52.9のサポートが終わる2018年8月28日までは、Windows XP/Vistaのサポートも継続される。</p><p>また、上記アナウンス後にThunderbird開発者のJörg Knobloch氏は、次期安定版がThunderbird 60になると<a href="https://groups.google.com/d/msg/tb-planning/Tgn50jqkn1o/C0g3aMEDAgAJ" title="Thunderbird 59 or 60? - Google グループ">明言した</a>。</p><p>なお、本文で触れたPolicy Engineは、プロトタイプの開発が進んでいる(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1419102" title="1419102 - Prototype an enterprise policy manager to allow rules set on enterprise deployments">Bug 1419102</a>)。</p> Rockridge 日本語版Firefox 58では初期登録のフィードリーダーが3つに hatenablog://entry/8599973812327206073 2017-12-16T23:02:54+09:00 2017-12-16T23:02:54+09:00 以前の記事で紹介したように、日本語版Firefox 57において初期登録のフィードリーダーが大幅に変更された。具体的には、Live Dwango Reader(LDR)が削除された一方で、AOL Reader、Feedly、Feed WatcherおよびInoreaderが追加された(Bug 1383654)。しかし、AOL Readerは2018年1月3日をもってサービスが終了する。これを受けて、同年1月23日(米国時間)にリリース予定のFirefox 58では、AOL Readerが初期登録から外される(Bug 1423585)。これで、残るフィードリーダーは次の3つに絞られた。 Feed… <p><a href="http://rockridge.hatenablog.com/entry/2017/09/10/215700" title="日本語版Firefoxに初期登録されるフィードリーダーをどうするか(再追記あり) - Mozilla Flux">以前の記事</a>で紹介したように、日本語版Firefox 57において初期登録のフィードリーダーが大幅に変更された。具体的には、Live Dwango Reader(LDR)が削除された一方で、AOL Reader、Feedly、Feed WatcherおよびInoreaderが追加された(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1383654" title="1383654 - Remove Live Dwango Reader entry since it is discontinued at end of August">Bug 1383654</a>)。</p><p>しかし、AOL Readerは2018年1月3日をもってサービスが<a href="http://reader.aol.com/eos">終了する</a>。これを受けて、同年1月23日(米国時間)にリリース予定のFirefox 58では、AOL Readerが初期登録から外される(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1423585" title="1423585 - [ja] Remove AOL Reader from feed reader options">Bug 1423585</a>)。これで、残るフィードリーダーは次の3つに絞られた。</p> <ul> <li><strong>Feedly</strong></li> <li><strong>Feed Watcher</strong></li> <li><strong>Inoreader</strong></li> </ul><p>ちなみに、Firefox本体に登録されたフィードリーダーを使用する際は、まずメニューパネルからカスタマイズ画面を開き、「購読」アイコンをツールバーに追加する。</p><p><figure class="figure-image figure-image-fotolife" title="Firefox Quantumのカスタマイズ画面"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171216/20171216225024.png" alt="f:id:Rockridge:20171216225024p:plain" title="f:id:Rockridge:20171216225024p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>Firefox Quantumのカスタマイズ画面</figcaption></figure></p><p>Webサイトに登録可能なフィードがある場合は、この「購読」アイコンが有効になるのでクリックし、ドロップダウンメニューからライブブックマークの代わりに自分で使っているサービスを選択すればOKだ。</p><p><figure class="figure-image figure-image-fotolife" title="フィードリーダーの選択画面"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171216/20171216225342.png" alt="f:id:Rockridge:20171216225342p:plain" title="f:id:Rockridge:20171216225342p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>フィードリーダーの選択画面</figcaption></figure></p> Rockridge Firefox 58以降も続く高速化と応答性向上 2018年もパフォーマンス2倍が目標 hatenablog://entry/8599973812323456991 2017-12-04T00:34:42+09:00 2017-12-05T07:44:20+09:00 2018年も飛躍的進歩へ Firefox Quantumのリリースは大きな注目を集め、そのスピードの速さと軽快さは、多くのユーザーから驚きをもって迎えられている。一方、非難の声が一部にあるのも事実だ。いわく、Chromeと同程度の速度でChrome互換の拡張機能が使えるだけであれば、Firefoxを選ぶ理由がない、と。だが、Firefoxが2017年に達成した高速化を、2018年も達成するとしたらどうだろう。Mozilla Corp.でSenior Vice President, Firefoxを務めるMark Mayo氏は、「今年(2017年)Firefoxのパフォーマンスは2倍になった。2… <div class="section"> <h4>2018年も飛躍的進歩へ</h4> <p>Firefox Quantumのリリースは大きな注目を集め、そのスピードの速さと軽快さは、多くのユーザーから驚きをもって迎えられている。一方、非難の声が一部にあるのも事実だ。いわく、Chromeと同程度の速度でChrome互換の拡張機能が使えるだけであれば、Firefoxを選ぶ理由がない、と。</p><p>だが、Firefoxが2017年に達成した高速化を、2018年も達成するとしたらどうだろう。Mozilla Corp.でSenior Vice President, Firefoxを務めるMark Mayo氏は、「今年(2017年)Firefoxのパフォーマンスは2倍になった。2018年も再び2倍にするのが暫定的な目標だ」と米CNETの<a href="https://www.cnet.com/news/firefox-quantum-update-mozilla-brings-speed-and-a-new-look/" title="Firefox Quantum update brings double the speed - CNET">取材に対し答えている</a>。同社のFellowを務めるDavid Bryant氏(Emerging Technologiesグループの事実上のトップ)も、Firefox 57時点のFirefox Quantumは<a href="https://medium.com/mozilla-tech/a-quantum-achievement-d7aa759a0ccb" title="A Quantum Achievement: But it’s Just the Beginning">序章に過ぎない</a>と述べている。</p><p>通常、この手の表現はマーケティング的に「盛っている」ものだが、こと2018年のFirefoxに限っては、あながち誇張とも言えない。これは<a href="http://rockridge.hatenablog.com/entry/2017/10/01/231017" title="Firefox Quantum雑感 - Mozilla Flux">以前の記事</a>に書いたことの裏返しになるが、QuantumプロジェクトはFirefox 57時点で半ばしか達成しておらず、残りの成果物が2018年前半に投入されていくスケジュールになっているのだ。また、Quantumプロジェクト以外にも、Firefox Quantumのリリースに間に合わなかったもろもろの新機能があって、完成したものから順にFirefox 58以降で有効化されていく。さらに、Quantum Flowが実証したように、細かな修正も積み重なると大きなパフォーマンスアップにつながるわけだが、2017年中に作られた下地がそこで生きてくる。</p> </div> <div class="section"> <h4>投入予定の新機能について</h4> <div class="section"> <h5>Firefox 58</h5> <p>処理速度の向上に関しては、JavaScript Start-up Bytecode Cache(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1405738" title="1405738 - Enable the JavaScript Start-up Bytecode Cache by default">Bug 1405738</a>)が大きいだろう。Webページ閲覧時に生成されたJavaScriptのバイトコードを、アイドル時にキャッシュしておき、再訪時に利用する機能だ。GoogleやFacebookのようにJavaScriptを多用するページでは、読み込み速度が15~20%も短縮される場合があるという。加えて、Windows版ではビルド環境がVisual Studio 2017 v15.4.1に変更されており(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1408789" title="1408789 - Use VS2017 for official Windows builds">Bug 1408789</a>)、コンパイルされたバイナリの<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1356654#c6" title="1356654 - Investigate performance from VS2017's new optimizer">性能が上がる</a>。</p><p>応答性の向上に関しては、Places Async Transactions(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1404267" title="1404267 - make Places Async Transactions ride the train to beta 58.">Bug 1404267</a>)を挙げることができる。履歴とブックマークのデータベース(Places)におけるトランザクションが非同期化され、Firefox本体が行う他の処理が阻害されない。特にFirefox Syncを利用している場合に、効果を実感できるだろう。</p><p>また、Quantum DOMの成果となるBudget Throttling(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1377766" title="1377766 - Enable budget throttling by default">Bug 1377766</a>)も見逃せない。これまでもFirefoxにはバックグラウンドタブにおけるスクリプトの処理を<a href="https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout#Reasons_for_delays_longer_than_specified" title="WindowOrWorkerGlobalScope.setTimeout() - Web APIs | MDN">抑制する技術</a>が組み込まれてきたが、Budget Throttlingはその最新のものとなる。<a href="https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API#Policies_in_place_to_aid_background_page_performance" title="Page Visibility API - Web APIs | MDN">大まかな仕組み</a>はこうだ。タブごとに処理時間の割当てが行われ、毎秒その処理時間が増加していく一方で、タスクが実行されるとその実行時間分だけ処理時間が減少する。割り当てられた時間がマイナスのときはタスクが実行されないので、バックグラウンドで繰り返し実行されるスクリプトは処理が抑えられる。ただし、音声を流す処理、リアルタイムコネクション絡みの処理(WebSocketsやWebRTC)とIndexedDBの処理はその例外となる。Budget Throttlingは、応答性の向上だけでなく、消費電力の低減にも効果があるとされる。</p> </div> <div class="section"> <h5>Firefox 59</h5> <p><a href="https://mozillagfx.wordpress.com/2017/09/21/introduction-to-webrender-part-1-browsers-today/" title="Introduction to WebRender – Part 1 – Browsers today – Mozilla Gfx Team Blog">Introduction to WebRender – Part 1 – Browsers today – Mozilla Gfx Team Blog</a>で説明されているように、Geckoのグラフィックス・パイプラインは、DOMツリー → フレームツリー → ディスプレイリスト → レイヤーツリーの流れで処理されていき、compositorがレイヤーツリーを合成する。新機能のOff Main Thread Painting(OMTP)は、「ディスプレイリスト → レイヤーツリー」の処理であるPaintingをメインスレッドとは別のところで行い、Firefox本体の応答性を高める(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1403957" title="1403957 - OMTP rides the trains">Bug 1403957</a>)。</p><p><figure class="figure-image figure-image-fotolife"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171204/20171204000145.png" alt="f:id:Rockridge:20171204000145p:plain" title="f:id:Rockridge:20171204000145p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>Geckoのグラフィックス・パイプライン</figcaption></figure></p><p>また、<a href="https://groups.google.com/forum/#!topic/mozilla.dev.platform/jSuLiuXqs8w" title="Intent to ship: Retained Display Lists - Google グループ">Retained Display Lists</a>(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1352499" title="1352499 - [meta] Retain and incrementally update display lists">Bug 1352499</a>)は、ディスプレイリストと呼ばれる描画命令のリストを構築するにあたって、常にスクラッチから行うのではなく、基本的にリストを保持しつつ部分的にアップデートしていく。YouTubeやTwitterで描画がスムーズになるという。</p> </div> <div class="section"> <h5>Firefox 60以降</h5> <p>Quantumプロジェクトの掉尾を飾るのが<a href="https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/" title="The whole web at maximum FPS: How WebRender gets rid of jank – Mozilla Hacks – the Web developer blog">Quantum Render</a>である。このサブプロジェクトでは、ServoのグラフィックスエンジンであるWebRenderをGeckoに移植する。最近のGPUは強力で、高精細なゲームをスムーズに処理できるのだから、Webページも同じように処理できるはず。この発想をベースに、Rust言語製のQuantum RenderはWebページを表示する際、ゲームエンジンのようにGPUを活用。Painting/Compositingの区別を取り払い、スクリーン全体を描画することで常時60fpsを実現するのである。</p><p>もっとも、従来とはアーキテクチャがあまりに異なっているし、GPUやグラフィックドライバーによる差異も吸収しなければならないので、開発には予想以上に時間がかかっている。今のところ機能の範囲を絞ってFirefox 60に投入されるのではないかとみられているが、Mozilla Corp.でDirector, Firefox Browsersを務めるJeff Griffiths氏は、Firefox Quantumの名称をFirefox 61/62まで使い続ける可能性を示唆しており、Quantum Renderの有効化が遅れる可能性もある。</p><p>また、同様にGPUを活用したRustベースのフォントラスタライザとして<a href="http://pcwalton.github.io/blog/2017/02/14/pathfinder/" title="Pathfinder, a fast GPU-based font rasterizer in Rust - pcwalton">Pathfinder</a>があり、Firefoxに統合されることが<a href="https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html" title="Fearless Concurrency in Firefox Quantum - The Rust Programming Language Blog">決まっている</a>。現時点でも<a href="https://twitter.com/pcwalton/status/925135450620039168">SVGレンダリング</a>を含め<a href="https://twitter.com/pcwalton/status/919311526703513600">基本的な処理</a>は行えるようになっているので、リリース時期はQuantum Renderとそう変わらないだろう。</p> </div> </div> <div class="section"> <h4>技術的負債の除去</h4> <p>2017年のFirefoxは、使用可能なプラグインを<a href="http://rockridge.hatenablog.com/entry/2016/10/16/231918" title="Firefox 52以降はFlash以外のプラグインが使用不可に こっそり使い続ける方法とは - Mozilla Flux">Adobe Flashに限定</a>し、Windows版の動作環境も<a href="http://rockridge.hatenablog.com/entry/2016/12/25/211343" title="FirefoxのWindows XP/Vistaサポートが2017年9月で終了へ(追記あり) - Mozilla Flux">Windows 7以降</a>とした。Firefox Quantumでは旧式アドオンの<a href="http://rockridge.hatenablog.com/entry/2017/02/19/231302" title="Firefoxでレガシーなアドオンが使えるのは2017年11月半ばまで - Mozilla Flux">サポートを打ち切った</a>。</p><p>これらの思い切った措置により、2018年のFirefoxは互換性の維持に煩わされることなく新機能を実装できるようになったし、古い環境を考えずにリファクタリングも行えるようになった。既に<a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XBL" title="XBL - Mozilla | MDN">XBL</a>はQuantum CSSやGeckoの処理を複雑化させるなど<a href="https://mozilla.github.io/firefox-browser-architecture/text/0005-problems-with-xbl.html" title="Problems with XBL">問題が多い</a>として段階的な削除が<a href="https://bgrins.github.io/xbl-analysis/" title="Are We XBL Still?">始まっている</a>。こうした動きは2018年の間じゅう続くだろう。</p> </div> <div class="section"> <h4>シェアの拡大を目指して</h4> <p>Mozillaの目標は、デスクトップ版Firefoxのグローバルなシェアを2020年までに20%にすることだ。そのためにはChromeからシェアを奪う必要があるわけだが、Mozillaのマーケティング戦略としては、自己の価値観に沿って市場で積極的な選択を行う層(これを&quot;Conscious Choosers&quot;と呼んでいる)がネットユーザーの約23%を占めるので、<a href="https://blog.mozilla.org/blog/2017/11/14/fast-for-good-launching-the-new-firefox-into-the-world/" title="Fast. For good. Launching the new Firefox into the World - The Mozilla Blog">その層を狙う</a>ということになっている。</p><p>だが、本当の意味でシェア拡大に寄与するのは、そうしたマーケティング上のあれやこれやではなくて、Firefoxの速さと軽さ、そしてそれがユーザーに受け入れられたときに生まれる「勢い」だ。もともとFirefoxはその方法で25%を超えるシェアを獲得した。逆に、痒いところに手が届くアドオンが豊富に使えることは、シェア低下の歯止めにはならなかった。Firefoxがかつてのシェアを取り戻そうとすれば、圧倒的な速さと軽さを実現し、維持するほかないし、旧式アドオンを支える仕組みはその足を引っ張っていたのだから、切り捨てる以外の選択肢はなかった。</p><p>WebExtensions移行プロジェクトの現場責任者であるAndy McKay氏は、プロジェクトの開始当初パニック状態にあり、落ち着いて取り組み始めてからも、Mozilla Corp.内でかなりの反対に遭ったと<a href="http://www.agmweb.ca/2017-10-27-here-we-are/" title="Andy McKay :: Here we are">告白している</a>。Mozillaが旧式アドオンを捨てることの重さをわかっていなかったはずはない。それでも、このタイミングでやらねばならなかったのである。決断の正しさは、2018年に明らかになるだろう。</p> </div> Rockridge Windows版Firefox Quantumではてなブックマーク拡張の日本語入力がおかしくなる問題の一時的な回避策 hatenablog://entry/8599973812320546985 2017-11-23T23:52:23+09:00 2017-12-29T09:27:57+09:00 2017年10月18日にはてなブックマークFirefox拡張がバージョン3.0.0へとアップデートされ(最新バージョンは3.0.2)、Firefox Quantum以降に対応するようになった。ところが、Windows版Firefox Quantumで日本語入力がおかしくなる問題が発生している。具体的には、ツールバー上のアイコンをクリックすると表示される、コメントの入力領域にIMEで入力する際、候補ウィンドウが常に画面の左上隅に出現する(Bug 1419285)。IMEの種類には関係がなく、Microsoft IMEはもちろん、ATOKやGoogle日本語入力でも現象は共通だ。候補を確定してしま… <p>2017年10月18日にはてなブックマークFirefox拡張がバージョン3.0.0へと<a href="http://bookmark.hatenastaff.com/entry/2017/09/26/160000" title="【実施済み】はてなブックマークFirefox拡張を10月中旬にアップデートいたします - はてなブックマーク開発ブログ">アップデート</a>され(最新バージョンは3.0.2)、Firefox Quantum以降に対応するようになった。ところが、Windows版Firefox Quantumで日本語入力がおかしくなる問題が発生している。</p><p>具体的には、ツールバー上のアイコンをクリックすると表示される、コメントの入力領域にIMEで入力する際、候補ウィンドウが常に画面の左上隅に出現する(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1419285" title="1419285 - IME candidate window position is always top-left when using Hatena Bookmark Web Extension">Bug 1419285</a>)。IMEの種類には関係がなく、Microsoft IMEはもちろん、ATOKやGoogle日本語入力でも現象は共通だ。候補を確定してしまえば文字列が入力領域に現れるとはいえ、拡張機能の使い勝手が損なわれることおびただしい。</p><p>実は、この問題はWebExtensionsベースの拡張機能が表示するパネルであれば、どこでも起きうるもの。はてなブックマーク拡張側の不具合ではない。Windows版Firefox 56においてWebExtensionsベースの拡張機能には<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1357486" title="1357486 - Turn on OOP extensions by default on Windows">まとめて1つのプロセスを割り当てた</a>のだが、この状態だとIME入力時にパネルにうまくフォーカスが当たらず、上記の現象が発生してしまうようなのだ。拡張機能の別プロセス化はマルチプロセス機能(e10s)の有効化が前提であり、e10sが全面有効化されてかつ拡張機能がWebExtensionsに限定されたFirefox Quantumで、問題が一挙に顕在化したというわけ。</p><p>現在Mozillaの開発者が対処にあたっており、Firefox 58では<a href="https://twitter.com/makoto_kato/status/933316191749210112">修正される見通し</a>である。それまでは、拡張機能の別プロセス化を解除することで問題を一時的に回避できる。about:configの画面から<strong>extensions.webextensions.remote</strong>の設定をfalseに変更すればOK。ただ、拡張機能の別プロセス化は、拡張機能がFirefox本体を巻き込んでクラッシュしたり、本体の応答性を低下させたりするリスクを減らすために導入されたものなので、上記の設定変更によってそうしたリスクが高まることに注意してほしい。</p><p><em>(17/12/29追記)</em><br>上記Bug 1419285はFirefox 58で修正された。extensions.webextensions.remoteの設定がtrueのままでも、はてなブックマーク拡張への日本語入力は正常に行える。設定を変更している場合は、1月下旬にFirefox 58へアップデートした際、元に戻しておくべきだろう。</p> Rockridge Firefox Quantumでトラッキング防止機能の全面有効化が可能に hatenablog://entry/8599973812319291866 2017-11-19T22:53:03+09:00 2017-11-23T22:51:26+09:00 トラッキング防止の新設定 Firefox 42以降、プライベートブラウジングモードではトラッキング防止機能が有効化されるようになっているが、Firefox Quantumでは通常モードでもこの機能を有効化する設定が追加された(Bug 1393627)。トラッキング防止機能を有効化した場合、たとえばGoogleアナリティクスなどもブロックされるが、目に見える効果として大きいのは、一部の広告が出なくなる点だろう。設定を開くには、まずFirefoxのウィンドウの上部右隅からメニューパネルを開き、歯車のアイコンがついた「オプション」をクリックする。次いで南京錠のアイコンがついた〔プライバシーとセキュリ… <div class="section"> <h4>トラッキング防止の新設定</h4> <p>Firefox 42以降、プライベートブラウジングモードでは<a href="https://support.mozilla.org/en-US/kb/tracking-protection" title="Tracking Protection | Firefox Help">トラッキング防止機能</a>が<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1175606" title="1175606 - Private Browsing Mode should enable Tracking Protection by default">有効化される</a>ようになっているが、Firefox Quantumでは通常モードでもこの機能を有効化する設定が追加された(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1393627" title="1393627 - Expose the full TP UI preferences">Bug 1393627</a>)。トラッキング防止機能を有効化した場合、たとえばGoogleアナリティクスなどもブロックされるが、目に見える効果として大きいのは、一部の広告が出なくなる点だろう。</p><p>設定を開くには、まずFirefoxのウィンドウの上部右隅からメニューパネルを開き、歯車のアイコンがついた「オプション」をクリックする。次いで南京錠のアイコンがついた〔プライバシーとセキュリティ〕をクリック。画面を下にスクロールさせていくと、トラッキング保護<a href="#f-486d621b" name="fn-486d621b" title="本記事ではあえて公式とは違うトラッキング「防止」の呼称を用いている。通常、プライバシー保護といえばプライバシー「を」保護することを指すが、ここでいうトラッキング保護機能は、トラッキング「から」ユーザーを保護するものだ。プライバシー保護のためのトラッキング保護機能という呼び方は、どうも据わりが悪い。">*1</a>の欄が出てくる。初期設定は「プライベートウィンドウのみ」になっているが、これを「常に」に変更するとトラッキング防止機能が有効化される。</p><p><figure class="figure-image figure-image-fotolife"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171119/20171119210643.png" alt="f:id:Rockridge:20171119210643p:plain" title="f:id:Rockridge:20171119210643p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>Firefox Quantumの新しいトラッキング防止設定画面</figcaption></figure></p><p>ちなみに、『ブロックリストを変更』というボタンを押すと、リストの選択画面に移る。初期設定は簡易ブロックだが、より強力な広範ブロックを選ぶことも可能だ。<a href="#f-db7057c4" name="fn-db7057c4" title="リストの切り替えには本体の再起動を要するが、Firefox 58では不要になる(Bug 1363969)。">*2</a></p><p><figure class="figure-image figure-image-fotolife"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171119/20171119211140.png" alt="f:id:Rockridge:20171119211140p:plain" title="f:id:Rockridge:20171119211140p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>ブロックリストの選択画面</figcaption></figure></p><p>トラッキング防止機能の効果を確かめるため、同一のWebページで有効・無効を切り替えてみよう。本機能が無効(初期設定)の場合、記事の上側や右側に広告が表示されるのは、よくあることだ。本機能を有効化するとそうした広告が除去され、これに伴ってページの読み込みも高速化される。</p><p><figure class="figure-image figure-image-fotolife"><div class="images-row mceNonEditable"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171119/20171119211853.png" alt="f:id:Rockridge:20171119211853p:plain" title="f:id:Rockridge:20171119211853p:plain" class="hatena-fotolife" itemprop="image"></span><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171119/20171119211922.png" alt="f:id:Rockridge:20171119211922p:plain" title="f:id:Rockridge:20171119211922p:plain" class="hatena-fotolife" itemprop="image"></span></div><figcaption>左:初期設定 右:トラッキング防止機能有効</figcaption></figure></p><p>トラッキング防止機能が働いているときは、アドレスバーに盾のアイコンが表示される。サイト単位で有効・無効の切り替えを行うこともできるので、ふだんは有効化しておき、表示が崩れる場合だけ機能を無効化するといった使い方も可能だ。機能を有効化した直後にチュートリアルが出るようになっているので、内容を覚えておこう。</p><p><figure class="figure-image figure-image-fotolife"><div class="images-row mceNonEditable"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171119/20171119212712.png" alt="f:id:Rockridge:20171119212712p:plain" title="f:id:Rockridge:20171119212712p:plain" class="hatena-fotolife" itemprop="image"></span><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171119/20171119212728.png" alt="f:id:Rockridge:20171119212728p:plain" title="f:id:Rockridge:20171119212728p:plain" class="hatena-fotolife" itemprop="image"></span><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171119/20171119212740.png" alt="f:id:Rockridge:20171119212740p:plain" title="f:id:Rockridge:20171119212740p:plain" class="hatena-fotolife" itemprop="image"></span></div><figcaption>トラッキング防止機能のチュートリアル</figcaption></figure></p> </div> <div class="section"> <h4>Polarisイニシアティブの到達点</h4> <p>Firefoxのトラッキング防止機能は、提携先である<a href="https://disconnect.me/" title="Disconnect">Disconnect</a>の<a href="https://disconnect.me/trackerprotection" title="Online Privacy &amp; Security">トラッキング防止リスト</a>を使用している。追跡者のリストはオープンにされており、見直されることもある。また、すべての追跡者がシャットアウトされるわけではなく、Do Not Track(DNT)の設定を尊重するWebサイトが除外されるほか、ユーザーの利便性も考慮されているようだ。</p><p>Mozillaは、ユーザーのオンラインプライバシーの保護向上を目的とする<a href="https://wiki.mozilla.org/Polaris" title="Polaris - MozillaWiki">Polarisイニシアティブ</a>の一環として、2014年11月にこの機能の<a href="https://blog.mozilla.org/netpolicy/2014/11/10/introducing-polaris-privacy-initiative-to-accelerate-user-focused-privacy-online/" title="Introducing Polaris Privacy Initiative to Accelerate User-focused Privacy Online - Open Policy &amp; Advocacy">開発をアナウンス</a>し、前述のとおりFirefox 42で製品版に取り込んだ後も、全面有効化に向けた研究・開発を続けてきた。Firefox Quantumに導入された設定画面も、2016年1月に<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1235565" title="1235565 - [experiment] Show the preferences to enable Tracking Protection in non-private windows in more cases">Firefox Nightly 46</a>(開発版)で実装されていたものだ。</p><p>2016年9月下旬には<a href="https://testpilot.firefox.com/experiments/tracking-protection/" title="Firefox Test Pilot - Tracking Protection">Tracking Protection</a>がFirefox Test Pilotの<a href="https://blog.mozilla.org/blog/2016/09/28/three-new-test-pilot-experiments/" title="Firefox’s Test Pilot Program Launches Three New Experimental Features - The Mozilla Blog">実験に追加</a>され、2017年2月中旬まで実験が続けられた。そこで得られた知見は、&quot;<a href="https://medium.com/firefox-test-pilot/test-pilot-tracking-protection-graduation-report-7452b5ccc477" title="Test Pilot Tracking Protection Graduation Report – Firefox Test Pilot – Medium">Test Pilot Tracking Protection Graduation Report</a>&quot;という記事にまとめられている。実験の際、ユーザーがトラッキング防止機能を無効化したWebサイトは少なかったようだが、ユーザーからのフィードバックを受けたMozillaがDisconnectと協議し、たとえばTwitterに投稿された画像がブロックされないように調整したそうだ。</p><p>その後も1万9000人以上を対象にした詳細な実地試験を経て、2017年8月にはトラッキング防止機能を有効化しても、恐れていたほどWebサイトの表示は崩れないとの<a href="https://docs.google.com/presentation/d/1OVtXAnyeBLX2N1yyZoTMP9AV_6HnI3mnXwIFlOL7yOA/edit#slide=id.g251dbe7f10_0_14" title="Privacy Settings Breakage Study, Aug 2017 - Google Slides">結論が得られた</a>。この結論がFirefox Quantumにおける設定追加の前提となっているとみられる。</p><p>Firefox Quantumでトラッキング防止機能の全面有効化が可能となった背景には、こうした過去の研究・開発の積み重ねがある。Polarisイニシアティブの1つの到達点と言えるだろう。拡張機能を入れなくても、設定を変更するだけで実効性のあるプライバシー保護の措置を講じられるというのは、素晴らしいことではないだろうか。</p><p><em>(17/11/23追記)</em><br>本記事掲載後、<a href="https://blog.mozilla.org/blog/2017/11/20/firefox-private-browsing-vs-chrome-incognito/" title="Firefox Private Browsing vs. Chrome Incognito: Which is Faster? - The Mozilla Blog">Firefox Private Browsing vs. Chrome Incognito: Which is Faster? - The Mozilla Blog</a>が速度向上に焦点を当ててトラッキング防止機能を紹介している。<a href="https://forest.watch.impress.co.jp/docs/serial/yajiuma/1092730.html" title="速くなったと評判の「Firefox Quantum」をもっと速く使う方法が明らかにされる - やじうまの杜 - 窓の杜">速くなったと評判の「Firefox Quantum」をもっと速く使う方法が明らかにされる - やじうまの杜 - 窓の杜</a>がこれを比較的詳しく取り上げているが、要するにMozillaに調査によれば、ページの読み込みに要する時間が半分以下になったという。</p><p>また、Tracking Protectionの公式な訳語が、「トラッキング保護」から「トラッキング防止」に<a href="https://github.com/mozilla-japan/gecko-l10n/issues/81" title="Tracking Protectionの翻訳はどれがいいのか · Issue #81 · mozilla-japan/gecko-l10n">変更されることになった</a>。関係者の迅速な対応に感謝したい。</p> </div><div class="footnote"> <p class="footnote"><a href="#fn-486d621b" name="f-486d621b" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">本記事ではあえて公式とは違うトラッキング「防止」の呼称を用いている。通常、プライバシー保護といえばプライバシー「を」保護することを指すが、ここでいうトラッキング保護機能は、トラッキング「から」ユーザーを保護するものだ。プライバシー保護のためのトラッキング保護機能という呼び方は、どうも据わりが悪い。</span></p> <p class="footnote"><a href="#fn-db7057c4" name="f-db7057c4" class="footnote-number">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text">リストの切り替えには本体の再起動を要するが、Firefox 58では不要になる(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1363969" title="1363969 - Changing blocklist requires a restart">Bug 1363969</a>)。</span></p> </div> Rockridge 旧式拡張機能からの移行例 hatenablog://entry/8599973812317237787 2017-11-14T01:19:38+09:00 2017-11-26T10:33:05+09:00 新形式の長所と短所 Firefox Quantumでは旧式の拡張機能が一切使えないようになっており、サポートされるのはChromeの拡張機能と共通する部分の多い新形式(WebExtensions)のものだけだ。Firefox 56以前で使用していた拡張機能が既にこの新形式に移行している場合はいいが、そうでなければ同じような機能を提供する別の拡張機能を探す必要がある。もっとも、新形式の拡張機能は従来よりも制約が大きい。旧式拡張機能の時代に、Firefox本体を大幅に書き換えることさえ許容していた結果、さまざまなバグの温床となったうえ、拡張機能の互換性を維持することが重荷にもなっていたことに対する… <div class="section"> <h4>新形式の長所と短所</h4> <p>Firefox Quantumでは旧式の拡張機能が一切使えないようになっており、サポートされるのはChromeの拡張機能と共通する部分の多い新形式(WebExtensions)のものだけだ。Firefox 56以前で使用していた拡張機能が既にこの新形式に移行している場合はいいが、そうでなければ同じような機能を提供する別の拡張機能を探す必要がある。</p><p>もっとも、新形式の拡張機能は従来よりも制約が大きい。旧式拡張機能の時代に、Firefox本体を大幅に書き換えることさえ許容していた結果、さまざまなバグの温床となったうえ、拡張機能の互換性を維持することが重荷にもなっていたことに対する反省を踏まえ、新形式では拡張機能ができることを絞ったのだ。特に、Firefox本体のユーザーインターフェイス(UI)にはごく限定された範囲でしか介入できないようになっている。そのため、従来のようなオールインワン型の拡張機能(Tab Mix Plusなど)は作成が極めて難しくなっている。</p><p>新旧の差は相当なもので、旧式拡張機能の新形式への移行は<a href="https://twitter.com/piro_or/status/926149716110229505">同じコンセプトの拡張機能を作り直すのに等しい</a>という意見が出るほどだ。しかも、Firefox 56までの間に新旧の<a href="https://blog.mozilla.org/addons/2017/03/17/migrating-webextensions-dont-forget-users/" title="Migrating to WebExtensions? Don’t Forget Your Users | Mozilla Add-ons Blog">ハイブリッド形式</a>に移行しておかないと、設定の受渡しもできない。</p><p>その代わり、拡張機能のインストール・アンインストールや有効・無効の切り替えの場面で、Firefox本体の再起動が例外なく不要となった。これによって、新しい拡張機能を気軽に試すことができるし、一部の拡張機能をふだんは無効にしておいて、必要になったら有効化するといった使い方でも支障がなくなる。それに、拡張機能がFirefox本体の速度や応答性を低下させる度合いは、かつてと比べ大きく軽減されている。</p><p>新形式の長所はそれだけにとどまらない。拡張機能の互換性が重視されているので、たとえば今インストールした拡張機能が2年後にも正常に動作している可能性は高いだろう。安定性の面では、今のところ<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1357486" title="1357486 - Turn on OOP extensions by default on Windows">Windows版のみ</a>だが、拡張機能全体に1つの独立したプロセスを割り当てているため、Firefox本体を巻き込んで落ちるケースも少なくなるはずだ。加えて、Firefox Syncを利用して<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1220494" title="1220494 - [tracking] Implement chrome.storage.sync">拡張機能が</a><a href="https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/storage/sync" title="storage.sync - Mozilla | MDN">設定を同期させる</a>ことも容易になった。</p> </div> <div class="section"> <h4>筆者のケース</h4> <p>今まで使っていた拡張機能がバージョンアップしないとか、バージョンアップしても機能が限定されてしまったという場合、前述のとおり新形式の拡張機能には仕様上の限界があるので、好みの環境を作り上げていくには、単機能の拡張機能を新たに見つけ出して、うまく組み合わせる必要がある。</p><p>Firefox Quantum以降、本体のアドオンマネージャーには〔旧式の拡張機能〕欄に「代わりのアドオンを探す」というボタンが付いており、新しい拡張機能を見つける際の助けになってくれる。また、英語が前提ではあるが<a href="https://mozilla.github.io/extension-finder/" title="Extension Finder">Extension Finder</a>というツールもある。</p><p>筆者の場合、Firefoxの開発版を常用しているので、早い段階から旧式拡張機能の廃止という問題に取り組まねばならなかった。現在も試行錯誤の途中ではあるが、インストールしている拡張機能は、ひとまず次のようなリストに落ち着いている。</p> <ul> <li><a href="https://addons.mozilla.org/ja/firefox/addon/adblock-plus/" title="Adblock Plus">Adblock Plus</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/chrome-store-foxified/" title="Chrome Store Foxified">Chrome Store Foxified</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/close-tabs-left/" title="Close Tabs to the Left">Close Tabs to the Left</a></li> <li>Feedly はてブ</li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/font-inspect/" title="Font Finder (revived)">Font Finder (revived)</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/gesturefy/" title="Gesturefy">Gesturefy</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/holdtab/" title="HoldTab">HoldTab</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/in-my-pocket/" title="In My Pocket">In My Pocket</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/neat-url/" title="Neat URL">Neat URL</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/open-in-chrome-browser/" title="Open in Google Chrome Browser">Open in Google Chrome Browser</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/open-in-microsoft-edge-browser/" title="Open in MS Edge™ Browser">Open in MS Edge™ Browser</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/selection-context-search/" title="Selection Context Search">Selection Context Search</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/vyrtsev-tab-saver/" title="Tab Saver">Tab Saver</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/tampermonkey/" title="Tampermonkey">Tampermonkey</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/translate-now/" title="Translate Now">Translate Now</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/uautopagerize/" title="uAutoPagerize">uAutoPagerize</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/url2clipboard/" title="URL をクリップボードにコピー">URL をクリップボードにコピー</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/zoom-image/" title="ZoomImage - 画像拡大">ZoomImage - 画像拡大</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/text-link/" title="テキストリンク (Text Link) ">テキストリンク (Text Link)</a></li> <li><a href="https://addons.mozilla.org/ja/firefox/addon/hatena-bookmark/" title="Hatena Bookmark">はてなブックマーク</a></li> </ul><p>Adblock Plusは言わずと知れた広告ブロッカーだ。<a href="https://addons.mozilla.org/ja/firefox/addon/ublock-origin/" title="uBlock Origin">uBlock Origin</a>も新形式に対応しているので、どちらを取るか迷うところではある。新規にインストールするのであれば、<a href="https://raw.githubusercontent.com/k2jp/abp-japanese-filters/master/abpjf.txt">ABP Japanese filters</a>の設定が簡単なuBlock Originのほうがよいかもしれない。</p><p>Chrome Store Foxifiedは当ブログで<a href="http://rockridge.hatenablog.com/entry/2017/01/09/192253" title="Chrome向けFeedlyはてブ拡張をFirefoxで使う方法 - Mozilla Flux">過去に紹介した</a>ことがある。Chromeウェブストアに登録されている拡張機能を、いわば強引にFirefoxで動かすためのツールだ。&quot;Feedly はてブ&quot;はこのツールを用いてFirefox版に変換したものを使っているが、ブックマーク数は問題なく表示されている。</p><p>Close Tabs to the Leftは左側のタブをすべて閉じる機能を追加するもの。個人的にはそこそこ使うので、オプションとしてFirefox本体に取り込んでほしい。</p><p>Font Finder (revived)はWebページ内で用いられているフォントを調べる際に使う。できればChrome向け拡張機能であるWhatFontのようなものが欲しいところ。あるいは、ウェブ開発ツールのインスペクターにこの機能が入っているべきなのかも。</p><p>Gesturefyはジェスチャー機能を追加してくれる。作り込まれた設定画面を備えており、マウスジェスチャーやホイールジェスチャーのカスタマイズも可能だ。筆者はホイールジェスチャーにタブの切り替えを当てていて、コンテンツ内でマウスの右ボタンを押したままホイールを回すことによって、タブの切り替えが行われるようにしている。</p><p>HoldTabは現在のタブ以外のタブについて、読み込みを保留しておけるので、たくさんのブックマークを一気に開く場合に重宝する。ただ、リンクを新しいタブで開くだけでも保留になってしまうため、ふだんは無効にしている。</p><p>In My Pocketは、かつて存在していた公式拡張機能のように、Pocketに保存した記事をリスト表示し、保存済み記事のURLを開いたときはアイコンの色が変わって知らせてくれる。これらの機能もFirefox本体に備わっているべきだと思う。</p><p>Neat URLはWebページのURLにくっついているパラメータを自動的に除去する。設定画面で対象パラメータを指定できる点もポイントが高い。余計なものを取り払うことで、そのページがはてなブックマークに登録済みかどうかの判別もしやすくなる。</p><p>Open in Google Chrome BrowserとOpen in MS Edge™ Browserは、文字通り現在開いているURLを他のブラウザで開き直すものだが、利用の前にNode.js製の<a href="https://github.com/andy-portmen/native-client/releases">ネイティブクライアント</a>をインストールしておかないといけない。各OS用のものが用意されていて、Windows版だとバッチファイルがあるので、インストール・アンインストールは難しくない。が、外部のアプリケーションと連携する際にこうした手間がかかるのは、新形式の拡張機能のデメリットだ。</p><p>Selection Context Searchは選択した文字列を既定以外の検索エンジンで検索可能にする。ユーザー側で検索用のURLを指定せねばならず、コンテキストメニューに表示される項目を調整する手間もかなりかかるため、不満もあるのだが、既定のGoogle以外に「英辞郎」と「Wikipedia」と「Bugzilla@Mozilla」を検索に含めたいというマニアックな要求を満たす方法としては、今のところこれしかない。</p><p>Tab Saverは特定のウィンドウにおけるタブ列のURLを一括して保存するツールだ。タブ列には年月日と日時(分単位)によって構成された表題が自動的に付加される。<a href="https://addons.mozilla.org/ja/firefox/addon/onetab/" title="OneTab">OneTab</a>をシンプルにした感じで、Webページのタイトルやセッション情報も保存されないし、1分あたり1つしかタブ列を保存できない欠点もあるものの、操作の手軽さが気に入っている。</p><p>Tampermonkeyはユーザースクリプトの管理と実行を担う。<a href="https://addons.mozilla.org/ja/firefox/addon/greasemonkey/" title="Greasemonkey">Greasemonkey</a>が新形式に移行する際にスクリプトの互換性を犠牲にしてしまったので、乗り換えた。といっても、組み込んでいるスクリプトは<del>Direct Googleと</del><a href="http://furyu.hatenablog.com/entry/20160116/1452871567#%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%88Greasemonkey--Tampermonkey%E7%89%88FirefoxGoogle-ChromeEdgeOpera%E5%AF%BE%E5%BF%9C" title="Twitter 原寸びゅー:原寸画像を開く拡張機能&ユーザースクリプト(PC用Google Chrome・Firefox・Opera等対応) - 風柳メモ">Twitter原寸びゅー</a>くらいだが。</p><p>Translate Nowは指定した翻訳エンジンによって翻訳されたWebページを別タブで開く。ドイツ語で書かれた<a href="https://www.soeren-hentzschel.at/" title="soeren-hentzschel.at - Aktuelles zu Mozilla">soeren-hentzschel.at</a>の記事をGoogle翻訳で英語に変換して読むのに使っているが、本当はChromeのように自動翻訳機能をFirefox本体に実装してほしい。</p><p>uAutoPagerizeは次のページを自動的に読み込んで、現在のページに継ぎ足してくれる。設定画面で実行しないページを指定することも可能だ。旧式拡張機能の時代には同種のものがいくつかあったと記憶しているが、新形式に対応したものは今のところこれだけではないか。</p><p>&quot;URL をクリップボードにコピー&quot;は、主にドキュメント自体のURLをHTML形式でクリップボードにコピーしたいときに使う。テキストをあらかじめ選択しておくと、リンクの内容に反映される点もよい。</p><p>&quot;ZoomImage - 画像拡大&quot;はページ内画像の拡大だけでなく縮小・回転もこなす。画像を浮かせる機能もある。ただ、筆者の環境ではGesturefyのホイールジェスチャーとキー設定が衝突してしまう。</p><p>&quot;テキストリンク (Text Link)&quot;は、リンクになっていないURLをダブルクリックすることで、そのURLが新しいタブに読み込まれるというもの。信頼と実績のPiroブランドである。</p><p>&quot;はてなブックマーク&quot;は、はてなブックマークの<a href="http://bookmark.hatenastaff.com/entry/2017/09/26/160000" title="【実施済み】はてなブックマークFirefox拡張を10月中旬にアップデートいたします - はてなブックマーク開発ブログ">公式拡張機能</a>であり、Chrome版を移植したため従来のものとは使い勝手が大幅に変わっている。タブを切り替えるとブックマークコメントの入力ウィンドウが閉じてしまう仕様だけは何とかならないものか。</p> </div> <div class="section"> <h4>お役御免となった拡張機能</h4> <p>前記の新環境となった結果、FireGesturesはGesturefyに、GreasemonkeyはTampermonkeyに、image-resizerは&quot;ZoomImage - 画像拡大&quot;に、Load Tabs Progressively FixedはHoldTabに、Make Linkは&quot;URL をクリップボードにコピー&quot;に、Open WithはOpen in Google Chrome BrowserとOpen in MS Edge™ Browserに、それぞれ置き換えられた。</p><p>また、長らく使用してきたSave Sessionについては、「以前のセッションを復元」の項目がFirefox Quantum以降メニューパネルの<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1393343" title="1393343 - Move &quot;Restore Previous Session&quot; Menu Item from Library&gt;History to the Menu.">最上位の階層に配置</a>されるようになったこともあり、Tab Saverに道を譲ってもらうことにした。</p><p>他方で、移行ができなかった拡張機能もある。Clear Fields(フィールドの消去)、Configuration Mania(本体設定のチューニング)、FEBE(拡張機能のバックアップ)、IME自動無効(アドレスバーのフォーカス時にIMEを無効化)、Menu Wizard(コンテキストメニュー等の項目の並べ替えや隠蔽)は、Firefox本体のUIや設定をいじらせないというMozillaの方針により、機能的に実現不可能となった。新形式への移行はもちろん、代替拡張機能も存在しない。</p><p><a href="https://addons.mozilla.org/ja/firefox/addon/multiple-tab-handler/" title="マルチプルタブハンドラ (Multiple Tab Handler)">マルチプルタブハンドラ (Multiple Tab Handler)</a>についても、<a href="https://addons.mozilla.org/ja/firefox/addon/tree-style-tab/" title="ツリー型タブ (Tree Style Tab)">ツリー型タブ (Tree Style Tab)</a>との<a href="http://piro.sakura.ne.jp/latest/blosxom/mozilla/extension/multipletab/2017-10-13_migration-we.htm" title="Latest topics &gt; マルチプルタブハンドラもWebExtensionsに移行しました - outsider reflex">連携にフォーカス</a>されて使い勝手が変わってしまったので、移行を見送った。Firefox Quantumだとタブの複製機能は<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=455722" title="455722 - Add context menu item to duplicate (clone) tab">本体に実装されている</a>し、左側のタブをすべて閉じる機能はClose Tabs to the Leftで間に合っている。将来的に<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=566510" title="566510 - Allow multiselect operations on tabs">タブの複数選択機能</a>もFirefoxの標準機能に加わる見込みなので、しばらくの辛抱だ。</p><p><em>(17/11/26追記)</em><br>本記事執筆後、Selection Context Searchの代わりに<a href="https://addons.mozilla.org/ja/firefox/addon/context-search-we/" title="Context Search WebExtension">Context Search WebExtension</a>を導入した。検索サービスを提供するWebサイトの検索窓からブックマークの&quot;Searches&quot;フォルダに、キーワードを設定した項目を登録しておくと、文字列選択時のコンテキストメニューにそれらが出てくる。検索サービスの管理がしやすく、上記フォルダ内に区切り線を入れておくとそれも反映されるので便利だ。</p><p>このように、本文のリストはあくまで本記事執筆当時のものなので、より便利な拡張機能が出てくれば乗り換えるのは当然だ。そこで、最新版を&quot;<a href="https://addons.mozilla.org/ja/firefox/collections/rockridge/must-have-extensions/" title="Must-have Extensions – Firefox 向けアドオン">Must-have Extensions</a>&quot;で公開することにした。Mozilla Add-ons(AMO)のコレクションである。よければ参考にしてほしい。</p><p>ちなみに、筆者の環境のユーザースクリプトについてだが、Direct Googleには引退してもらい、<a href="https://greasyfork.org/en/scripts/14150-google-%E7%BB%95%E8%BF%87%E6%90%9C%E7%B4%A2%E7%BB%93%E6%9E%9C%E7%BD%91%E9%A1%B5%E9%93%BE%E6%8E%A5%E9%87%8D%E5%AE%9A%E5%90%91" title="Google: Bypass Result Page Redirect">Google: Bypass Result Page Redirect</a>と<a href="https://greasyfork.org/en/scripts/725-google-cache-comeback" title="google cache comeback">google cache comeback</a>を追加したので、本文からDirect Googleを削除した。なお、参考記事も1つ追加した。</p><p><div class="refList"><br /> <em>参考記事</em><br /> </p> <ul> <li><a href="http://point2000.hatenablog.com/entry/2017/09/13/222108" title="FirefoxのWebextensionアポカリプスに備える(主要アドオンのWebextensions対応について) - 俺の話を聞いてくれ">FirefoxのWebextensionアポカリプスに備える(主要アドオンのWebextensions対応について) - 俺の話を聞いてくれ</a></li> <li><a href="https://00.bulog.jp/archives/164" title="Firefox57で使えなくなった代替アドオンのまとめ">Firefox57で使えなくなった代替アドオンのまとめ</a></li> <li><a href="http://nitteru.hatenablog.com/entry/2017/10/21/225038" title="FirefoxのアドオンをWeb Extensionsへ移行してみる - 日々是おやっとさぁ">FirefoxのアドオンをWeb Extensionsへ移行してみる - 日々是おやっとさぁ</a></li> <li><a href="http://a-kuma3.hatenablog.com/entry/welcome_firefox57" title="ようこそ、Firefox 57 @うちの事情 - おまえ、うまそうだな">ようこそ、Firefox 57 @うちの事情 - おまえ、うまそうだな</a></li> </ul><p></div></p> </div> Rockridge Firefox Quantum高速化の一翼を担うQuantum CSS hatenablog://entry/8599973812314820660 2017-11-05T23:36:33+09:00 2017-11-11T20:42:17+09:00 デスクトップ版Firefox Quantumでは、Quantum CSS(別名Stylo)と呼ばれる新しいCSSエンジンが初期設定で有効化されている(Bug 1330412)。CSSエンジンはレンダリングエンジンの構成要素の1つで、CSSパーサーとスタイルシステムから成り、HTMLパーサーが生成したDOMツリー(DOMノードが樹状に連なったもの)に対し、CSSを解釈してスタイルを計算した結果を当てはめていく。Quantum CSSは約8.5万行のRust言語のコードで構成される。Geckoの旧CSSエンジンは約16万行のC++言語のコードで構成されていたから、半分程度のコンパクトさだ。それでい… <p>デスクトップ版Firefox Quantumでは、Quantum CSS(別名Stylo)と呼ばれる新しいCSSエンジンが初期設定で有効化されている(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1330412">Bug 1330412</a>)。CSSエンジンはレンダリングエンジンの構成要素の1つで、CSSパーサーとスタイルシステムから成り、HTMLパーサーが生成したDOMツリー(DOMノードが樹状に連なったもの)に対し、CSSを解釈してスタイルを計算した結果を当てはめていく。</p><p>Quantum CSSは約8.5万行のRust言語のコードで構成される。Geckoの旧CSSエンジンは約16万行のC++言語のコードで構成されていたから、半分程度のコンパクトさだ。それでいて、Quantum CSSは旧CSSエンジンが設計の古さゆえに抱えてた<a href="https://developer.mozilla.org/ja/Firefox/Releases/57#Quantum_CSS_notes">様々な不具合を解消している</a>。もっとも、実装には苦労もあったようだ。font-sizeプロパティ1つとっても、いろんな単位をサポートしなければならないうえ、たとえば&quot;medium&quot;が何を指すかはフォントの系統ごとに変わってくるし、ルビやMathMLでの調整も必要になる。2015年の終わりころに開発が開始され、2年近い歳月を経てようやくFirefoxリリース版への搭載にこぎ着けた。</p><p>Quantum CSSは、Geckoの旧CSSエンジンからルールツリーの仕組みを引き継ぎつつ、Servoの並列処理の仕組みを取り入れるとともに、WebKit/Blinkのスタイル共有キャッシュに着想を得たキャッシュシステムを備えている。いわば各種ブラウザの最先端技術を融合させたCSSエンジンなのだ。</p><p><figure class="figure-image figure-image-fotolife"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171105/20171105213420.png" alt="f:id:Rockridge:20171105213420p:plain:w400" title="f:id:Rockridge:20171105213420p:plain:w400" class="hatena-fotolife" style="width:400px" itemprop="image"></span><figcaption>ベストミックスのCSSエンジン</figcaption></figure></p><p>スタイルシステムは一般に、CSSに記述されている各セレクターが対象となるDOMノードすべてについてマッチするかどうかの判定を行う(セレクターマッチング)。また、計算済みスタイルが適用されないDOMノードについては、親ノードから引き継いだスタイルまたはデフォルトのスタイルを適用する(カスケード)。インタラクティブなWebページの増加に伴い、これらの処理による負担は重くなる一方だ。</p><p>Quantum CSSでは、処理の並列化によってこの問題に対処する。すなわち、CPUのマルチコア化を前提に、DOMツリーを適宜分割して、スタイルに関する処理を各CPUコアに割り当てるのだ。CPUが4コアであれば4つの処理を同時にこなすことが可能になる。手が空いたコアは別のコアが担当予定の処理を取ってくるようになっている(work stealingという)ので、コアが遊んでしまうこともない。</p><p>また、Quantum CSSでは、計算済みスタイルをキャッシュしておき、同一のスタイルが適用されるノードに対しては重複した処理を行わないようにする。この場合キャッシュのマッチング処理が必要になるが、Quantum CSSのキャッシュシステムは疑似クラスが用いられるケースなども想定してキャッシュ利用の効率性を高めているという。</p><p>以上のほかにも多数の最適化が施されているQuantum CSSだが、その実力はどの程度のものだろうか。MozillaのビルドシステムがQuantum CSSの有効化時に行った<a href="https://treeherder.mozilla.org/perf.html#/alerts?id=9238">自動化テストの結果</a>によれば、<a href="https://wiki.mozilla.org/Buildbot/Talos/Tests#tp6">Amazon.comの読み込みテスト</a>(&quot;laptop&quot;のキーワードで検索した結果を25回表示させ、最初の5回を除いた20回について中央値を取ったもの)において、およそ25%の速度向上が見られた。コンテンツ次第ではあるが、複雑なページほど実力を発揮してくれそうだ。</p><p>他方、Quantum CSSに欠点がないわけではない。旧CSSエンジンよりもメモリ消費量は増えるようだ。それとは別に、互換性の問題もある。旧CSSエンジンでは正しく表示されていたWebサイトが、Quantum CSSだと表示がおかしくなるケースがありうる。そこで、Mozillaは問題の出たWebサイトにおいて旧CSSエンジンに切り替える仕組みを導入した(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1403077">Bug 1403077</a>)。</p><p>これまでに述べてきたとおり、Quantum CSSはコンテンツに適用されるものだが、Firefox本体のUI部分にも多数のCSSが用いられているので、その処理にQuantum CSSを適用するのは自然な発想といえよう。既にFirefox Nightly 58にはそうした仕組みが実装されており(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1411532">Bug 1411532</a>)、layout.css.servo.chrome.enabledの設定をtrueに変更すると有効化される。</p><p>Android版FirefoxにもQuantum CSSは投入される予定だ。Firefox Nightly 58には初期設定を無効にした形で実装済みで(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1411802">Bug 1411802</a>)、今後Nightly 59において<a href="https://groups.google.com/forum/#!topic/mozilla.dev.platform/CogfmMY2bLA">初期設定が有効に切り替わる</a>見通しだが、そのままリリース版まで維持されるかどうかは未定である。</p><p>将来的にQuantum CSSが必要な箇所すべてに適用され、互換性の問題も解消された暁には、旧CSSエンジンは削除されることになる(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1395112">Bug 1395112</a>)。つまり約16万行のC++コードがGeckoから消えてRustに置き換わるわけで、コードのメンテナンスしやすさや堅牢性といった点において大きなインパクトを与えるとみられる。</p><p><div class="refList"><br /> <em>参考記事</em><br /> </p> <ul> <li><a href="https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/">Inside a super fast CSS engine: Quantum CSS (aka Stylo) ★ Mozilla Hacks – the Web developer blog</a></li> <li><a href="https://www.joshmatthews.net/rbr17/#">The Story of Stylo</a></li> <li><a href="http://wontfix.blogspot.jp/2016/12/quantum-css-stylo.html">won't fix: Quantum CSS (Stylo)</a></li> <li><a href="https://manishearth.github.io/blog/2017/08/10/font-size-an-unexpectedly-complex-css-property/">Font-size: An Unexpectedly Complex CSS Property - In Pursuit of Laziness</a></li> <li><a href="http://takenspc.hatenablog.com/entry/2014/09/16/152157">CSSセレクターマッチングのコスト - Unreviewed</a></li> </ul><p></div></p><p><em>(17/11/06追記)</em><br>本文中の「DOMツリーを適宜分割して、スタイルに関する処理を各CPUコアに割り当てる」という記述が舌足らずであったように思うので、補足しておく。Quantum CSSがHTMLパーザーによって生成済みのDOMツリーを切り貼りするわけではない。そのような処理はCSSエンジンの守備範囲を超える。そうではなくて、スタイルシステムが担当する(親)ノードを決めるということが言いたかった。枝分かれするDOMツリーの一部をCPUコアAが、別の一部をCPUコアBがそれぞれ担当するのである。上記の記述は、「DOMツリーにおける担当領域を適宜分割して」と表現するのが適切であった。</p> Rockridge タブバー上の人型アイコンを消す(追記あり) hatenablog://entry/8599973812312582329 2017-10-29T23:43:37+09:00 2017-11-04T14:44:50+09:00 Firefox 57以降、アクセシビリティサービスが有効になっている環境では、タブバー上にその旨を示すインジケーターが表示されるようになっている(Bug 1383051)。インジケーターは人型のアイコンであり、色合いが背景と違うのでけっこう目立つ。タブバー上のインジケーターアクセシビリティサービスの典型はスクリーンリーダーであり、Firefoxにアクセスするそうしたサービスが存在するときは、原則としてトラブルシューティング情報(about:support)の〔アクセシビリティ〕欄において種類などを確認できる。問題は、高DPI環境でWindowsのディスプレイ設定が拡大表示になっている場合であっ… <p>Firefox 57以降、<a href="https://support.mozilla.org/en-US/kb/accessibility-services">アクセシビリティサービス</a>が有効になっている環境では、タブバー上にその旨を示すインジケーターが表示されるようになっている(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1383051">Bug 1383051</a>)。インジケーターは人型のアイコンであり、色合いが背景と違うのでけっこう目立つ。</p><p><figure class="figure-image figure-image-fotolife"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171029/20171029225459.png" alt="f:id:Rockridge:20171029225459p:plain" title="f:id:Rockridge:20171029225459p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>タブバー上のインジケーター</figcaption></figure></p><p>アクセシビリティサービスの典型は<a href="https://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%83%AA%E3%83%BC%E3%83%80%E3%83%BC">スクリーンリーダー</a>であり、Firefoxにアクセスするそうしたサービスが存在するときは、原則としてトラブルシューティング情報(about:support)の〔アクセシビリティ〕欄において種類などを確認できる。</p><p>問題は、高DPI環境でWindowsのディスプレイ設定が拡大表示になっている場合であっても、インジケーターが表示されてしまう点だ。アクセシビリティサービスを使っているつもりが全くないのに、タブバー上に目立つアイコンが表示され続けることになる。</p><p>このインジケーターを消す方法は2つある。1つは、インジケーターの表示設定を無効化すること。もう1つは、アクセシビリティサービスによるFirefoxへのアクセスを遮断することである。前者は、about:configのページでaccessibility.indicator.enabledの設定をfalseに変更すれば実現できる。</p><p>後者の方法はもっと簡単で、メニューの『オプション』から設定画面を開き、〔プライバシーとセキュリティ〕の許可設定欄にある「アクセシビリティサービスによるブラウザーへのアクセスを止める」にチェックを入れればOK。本体の再起動を要求されるので、これに応じるとチェックが有効化される。ちなみに、設定値としてはaccessibility.force_disabledが1に変更された形だ。</p><p><figure class="figure-image figure-image-fotolife"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171029/20171029232710.png" alt="f:id:Rockridge:20171029232710p:plain" title="f:id:Rockridge:20171029232710p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>設定画面からアクセシビリティサービスをオフに</figcaption></figure></p><p>積極的にアクセシビリティサービスを使っているのでなければ、Firefoxへのアクセスは遮断してしまっていいと思う。そうしたサービスがFirefoxにアクセスする場合、ブラウザとしては<a href="https://twitter.com/d_toybox/status/911243595075641344">処理を中断して応答しなければならず</a>、知らず知らずのうちに<a href="https://twitter.com/d_toybox/status/911202447229575168">パフォーマンスの低下を招いている</a>可能性もあるからだ。</p><p><em>(17/11/02追記)</em><br>ATOK 2016以降に搭載されているATOKインサイトが、Firefoxにはスクリーンリーダーとして認識されるという話がある。アクセシビリティサービスを遮断することでATOKインサイトが使えないと困る場合、インジケーターの表示設定を無効化するのがよいだろう。</p><p><blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">ATOKインサイトは、Firefoxからはアクセシビリティ機能に見えるらしく、E10s有効の場合は使えない。>マルチプロセスをサポートするモードではアクセシビリティ機能は利用できません | Firefox ヘルプ <a href="https://t.co/aCeuZcJ5a0">https://t.co/aCeuZcJ5a0</a></p>&mdash; Raven (@raven_si) <a href="https://twitter.com/raven_si/status/924868564904902657?ref_src=twsrc%5Etfw">2017年10月30日</a></blockquote><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script></p><p><em>(17/11/04追記)</em><br>Firefox 57 Beta 13以降、インジケーターは初期設定で非表示となった(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1411591">Bug 1411591</a>)。Mozillaの開発者によれば、Beta版ユーザーの約7%がこのインジケーターを目にしていたそうだが、どうやらこの割合はMozillaの想定を超えていたようだ。Firefox 57のリリース後に行われるテストの結果を踏まえて初期設定を決めることとなり、accessibility.indicator.enabledの設定はfalseに変更された。</p><p>本文にはあまり意味がなくなってしまったが、初期設定においてアクセシビリティサービスがFirefoxにアクセス可能である点は変わりがない。Firefoxのパフォーマンスがインストール当初から良くない場合、「アクセシビリティサービスによるブラウザーへのアクセスを止める」の設定を変更してみるのも1つの手だろう。</p> Rockridge Mozilla Add-ons(AMO)がFirefox Quantumの登場に備えてリニューアル予定 新デザインを採用しFirefoxに特化 hatenablog://entry/8599973812308325330 2017-10-15T23:10:47+09:00 2017-11-06T23:43:39+09:00 各種アドオンを掲載するMozilla Add-ons(以下AMO)は、2017年11月2日(米国時間)にデスクトップ版のフロントエンドがリニューアルされる予定だ。具体的には現在モバイル版で採用されているデザインが、デスクトップ版にも適用される。レスポンシブにも対応した新デザインは、現在パブリックベータの段階にあって誰でも試すことができる。AMOの一般向けページの末尾に「モバイル用サイトを表示」というリンクがあるはずだ。これをクリックするとデザインが切り替わる。戻すときは「通常のデスクトップ版サイトを表示」のリンクをクリックすればよい。なお、個別のアドオンのバージョン履歴のように切り替わらない部… <p>各種アドオンを掲載する<a href="https://addons.mozilla.org/">Mozilla Add-ons</a>(以下AMO)は、2017年11月2日(米国時間)にデスクトップ版のフロントエンドが<a href="https://mail.mozilla.org/pipermail/dev-addons/2017-October/003258.html">リニューアルされる予定</a>だ。具体的には現在モバイル版で採用されているデザインが、デスクトップ版にも適用される。</p><p>レスポンシブにも対応した新デザインは、現在パブリックベータの段階にあって誰でも試すことができる。AMOの一般向けページの末尾に「モバイル用サイトを表示」というリンクがあるはずだ。これをクリックするとデザインが切り替わる。戻すときは「通常のデスクトップ版サイトを表示」のリンクをクリックすればよい。なお、個別のアドオンのバージョン履歴のように切り替わらない部分も残っている。</p><p><figure class="figure-image figure-image-fotolife"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171014/20171014162726.png" alt="f:id:Rockridge:20171014162726p:plain" title="f:id:Rockridge:20171014162726p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>AMOのレスポンシブな新デザイン</figcaption></figure></p><p>新デザインは配色がFirefox Quantumに合わせたものとなっているほか、トップページに掲載される情報を整理し、個別のアドオンよりもユーザーの用途に着目した選択肢を提示するようになった。技術的にはサーバーサイドでレンダリングされるReactアプリであり、従来のDjangoベースから大きく変化している。</p><p><figure class="figure-image figure-image-fotolife"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171014/20171014162725.png" alt="f:id:Rockridge:20171014162725p:plain" title="f:id:Rockridge:20171014162725p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>拡張機能のページは中程に情報を集約</figcaption></figure></p><p>個別の拡張機能のページは2カラム式になった。中心的な情報を右側においてスペースを広く取る一方、その他の情報を左側に集約させている。スクリーンショットが大型化して目立つ位置にあり、拡張機能作者に掲載を促しているとみられる。拡張機能の説明も最初の段落だけが表示され、それ以上はユーザーが「詳しく見る」をクリックしないと出てこない。これも簡潔的確な説明を最初に載せるよう促す狙いだろう。なお、『作者のコメント』欄は見当たらなくなっている。</p><p>また、拡張機能をインストールするボタンは切り替え式になった。アドオンマネージャーの〔アドオンを入手〕で採用済みだが、オンにしてインストールすることはもちろん、オフにしてアンインストールすることも可能だ。WebExtensions拡張機能はすべて再起動が不要なので、アンインストールが簡単にできるメリットが際立つ。ただ、ボタンのサイズが小さい点と右端に寄りすぎている点は気になるところだ。</p><p>それから、レビューを書かなくても五つ星のレーティングが簡単に行えるようになっている。逆にレビューは、従来のように最新の一部が表示されることもなく、サブページに追いやられた。そのほうがユーザーの声を集めやすいという配慮だと思うが、賛否が分かれそうだ。</p><p>ちなみに、リニューアル後もFirefox ESR 52のサポートサイクルが続く2018年6月までは、AMOにおいて旧式アドオンの掲載が<a href="https://blog.mozilla.org/addons/2017/10/03/legacy-add-on-support-on-firefox-esr/">継続される</a>。旧式アドオンは最大バージョンが56.*となっているが、バージョン別の互換性フィルタが初期設定で<a href="https://blog.mozilla.org/addons/2017/08/10/upcoming-changes-compatibility/">無効化されている</a>ため、Firefox Quantumのリリース後もただちにWebExtensions未対応の拡張機能が探せなくなるわけではない。もっとも、WebExtensionsベースの拡張機能が検索の上位に表示されるような調整は施されているようだ。</p><p>AMOのリニューアルにあたってもう1つ大きな変化がある。それは、Firefox向け(デスクトップ版・Android版)への特化だ。Thunderbird/SeaMonkey向けのアドオンはAMOから切り離され、コミュニティベースで管理することになる。Thunderbirdであれば、Thunderbird Councilが管理を担当する。当面はMozillaがインフラを提供し、AMOから新サイトにリダイレクトされるものの、たとえばレビューチームは自分たちで組まなければならない。インフラの運用についても同様だ。</p><p><a href="https://docs.google.com/document/d/1_fs6FA7KlZsU9Jozyj6AcbmuP8ra3nODrp036w-rFuU/edit#">スケジュール</a>によれば、リダイレクトの開始は2017年11月10日がデッドラインとなっているが、その後11月2日のAMOリニューアルが決定されたため、リダイレクトもその日だろう。リダイレクト後は引継ぎ期間に移行し、2017年12月22日までに、Thunderbird向けアドオンを掲載する新サイトはThunderbird Councilが管理と運用を行う形となる。</p><p>以上のとおり、今回のAMOのリニューアルは根本的な変革だ。Firefoxの歴史にとってFirefox Quantumが重要なものとなるように、11月2日のリニューアルもAMOの歴史に深く刻まれることになるだろう。他方で、ユーザーは当初かなり戸惑うことになると思われる。フィードバック次第では、デザインの一部に修正が加えられる可能性もありそうだ。</p><p><em>(17/11/03追記)</em><br>予定通りAMOのリニューアルが<a href="https://mail.mozilla.org/pipermail/dev-addons/2017-November/003363.html">実施された</a>。開発には1年半以上を要したとのこと。表示速度の向上も大きなアピールポイントのようだ。</p><p><em>(17/11/05追記)</em><br><a href="https://www.ghacks.net/2017/11/03/mozilla-launches-redesigned-firefox-add-ons-website/">Mozilla launches redesigned Firefox Add-ons website - gHacks Tech News</a>で、リニューアル後のAMOにおいて利用可能なURLパラメータが紹介されている。以下のパラメータを「&amp;」記号でつなげると検索内容の調整が可能だ。</p> <ul> <li>sort=updated, relevance, users, rating, hotness</li> <li>type=extension, persona</li> <li>platform=windows, mac, linux</li> <li>featured=true</li> </ul><p><em>(17/11/06追記)</em><br>現行のAMOのデザインは、パブリックベータ版からも若干変わっている。個別の拡張機能のページでは、インストール用のボタンについて、切り替え式を廃して大きく目立つものを手の届きやすい場所に置いた。また、拡張機能を評価する欄を上側に移動させたほか、欄と欄の間隔や欄内の文字の配置に余裕をもたせた。今後もユーザーのフィードバックを受けながら調整を続けていくのだろう。</p><p><figure class="figure-image figure-image-fotolife"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171106/20171106233234.png" alt="f:id:Rockridge:20171106233234p:plain" title="f:id:Rockridge:20171106233234p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>AMO正式版のデザイン</figcaption></figure></p> Rockridge Firefox QuantumでThe Book of Mozillaも新章へ hatenablog://entry/8599973812306440891 2017-10-10T00:30:31+09:00 2018-04-30T20:47:53+09:00 Firefoxにはその前身であるNetscape Navigatorの時代から、about:mozillaのページに『モジラ書(The Book of Mozilla)』の一節を表示するイースター・エッグがある。文章が更新されるのは開発にとって大きな節目の時期となっており、Firefox Quantumもその節目に選ばれた(Bug 1370613)。つまりFirefox 57のabout:mozillaは、Firefox 56とは内容が違う。about:mozillaの11章14節about:mozillaの履歴は公式サイトに掲載されているが、英語版Wikipediaの"The Book of… <p>Firefoxにはその前身であるNetscape Navigatorの時代から、about:mozillaのページに『モジラ書(The Book of Mozilla)』の一節を表示するイースター・エッグがある。文章が更新されるのは開発にとって大きな節目の時期となっており、Firefox Quantumもその節目に選ばれた(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1370613">Bug 1370613</a>)。つまりFirefox 57のabout:mozillaは、Firefox 56とは内容が違う。</p><p><figure class="figure-image figure-image-fotolife"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171010/20171010003218.png" alt="f:id:Rockridge:20171010003218p:plain" title="f:id:Rockridge:20171010003218p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>about:mozillaの11章14節</figcaption></figure></p><p>about:mozillaの履歴は<a href="https://www.mozilla.org/en-US/book/">公式サイト</a>に掲載されているが、英語版Wikipediaの&quot;<a href="https://en.wikipedia.org/wiki/The_Book_of_Mozilla">The Book of Mozilla</a>&quot;の記事のほうが、背景の解説など関連情報まで載せてくれていて、はるかにわかりやすい。Firefox Quantumの新しい文章も反映されているなど目配りも利いており、資料的価値は高いといえる。</p><p>そのWikipediaの記事にも書かれているとおり、The Book of Mozillaは聖書うちの一書という体裁を強く意識している。いわばオープンソース聖書のようなものがある中で、旧約聖書の『ダニエル書』や新約聖書の『ヨハネの黙示録』のように、『モジラ書』は獣(the beast)が登場する黙示文学なのである。この獣(the beast)は、赤い恐竜のような姿で描かれた<a href="https://en.wikipedia.org/wiki/Mozilla_(mascot)">マスコットとしてのMozilla</a>をイメージしたもので、炎を吐く存在とされている。</p><p>The Book of Mozillaの初出は、1995年のNetscape Navigator 1.1である。以後Netscape Communicator 4.xまで、「12章10節」が掲載された。この章と節は記念となる出来事の月日を反映していて、12章10節というのも1994年12月10日にNetscape Navigator 1.0がリリースされたことを踏まえている。その文章を私訳とともに紹介しよう。</p> <blockquote> <p>And the beast shall come forth surrounded by a roiling cloud of vengeance. The house of the unbelievers shall be razed and they shall be scorched to the earth. Their tags shall blink until the end of days.</p><p>獣は復讐に燃える群衆に囲まれて現れるであろう。不信仰者らの住処は打ち壊され、焦土と化す。彼らの印は世の終わりまで明滅することとなる。</p> </blockquote> <p>ここでいう「不信仰者」は、Web標準に従わない人々を指す。Netscape 3までは内蔵のHTMLビューワでソースを見ると、誤ったタグ(印)が明滅する仕様になっていたことが、巧みに文章に盛り込まれている。</p><p>次の節目は、Netscapeのコードがオープンソース化された1998年3月31日だ。同年5月には早くもabout:mozillaの「3章31節(赤文字版)」が出来上がったものの、Mozillaのコードが書き換えられていく中でいったん失われた。2000年2月に復活し、Netscape 6から7.1に掲載されたのが次の文章である。</p> <blockquote> <p>And the beast shall be made legion. Its numbers shall be increased a thousand thousand fold. The din of a million keyboards like unto a great storm shall cover the earth, and the followers of Mammon shall tremble.</p><p>獣は大群となり、その数は千の千倍にも増える。無数のキーボードを打ち鳴らす音が大いなる嵐の如くなりて地を覆い、強欲の化身を奉ずる者らは打ち震えるであろう。</p> </blockquote> <p>ここで初めてマモン(Mammon)という言葉が出てくる。富を擬人化した存在で、悪魔学では強欲を司る悪魔とされているが、文章内ではMicrosoftの暗喩として用いられている。一神教の世界観なので書き手がマモンを「神」と呼ぶことはないが、悪魔と明示されているわけでもないので、訳文では「強欲の化身」とした。</p><p>文章に描かれているのは、Internet Explorerの攻勢にいったん破れたNetscapeが、オープンソースとして広く拡散し、反撃を開始する様だ。黙示文学の体裁ではあるが、キーボードという言葉が出てくるのは、宗教的な雰囲気になりすぎるのを避けたかったからだろう。ちなみに、「赤文字版」の赤文字(Red Letter)は「特筆すべき」くらいの意味だが、イエス・キリストの言葉のみ赤文字で書かれた新約聖書というものが存在するらしく、そのことも踏まえた凝ったネーミングになっている。</p><p>2003年7月15日、AOLがNetscape部門を閉鎖し、Mozilla Foundationが創設された。しかし、オープンソースであるMozillaのコードベースは存続し、後のFirefox(初期の名前はFirebird)やThunderbirdへと繋がっていく。Mozilla 1.5からFirefox 3.0 Beta 2まで、Thunderbirdの最初のバージョンから2.0.0.24まで、Netscape 7.2から8.1.3までなどに掲載されたのが次の「7章15節」である。</p> <blockquote> <p>And so at last the beast fell and the unbelievers rejoiced. But all was not lost, for from the ash rose a great bird. The bird gazed down upon the unbelievers and cast fire and thunder upon them. For the beast had been reborn with its strength renewed, and the followers of Mammon cowered in horror.</p><p>そのようにして獣はついに倒れ、不信仰者たちは歓喜した。しかし消え去ってはいなかった。その灰より大いなる鳥が蘇ったからである。鳥は不信仰者たちを睥睨し、炎と雷を彼らに浴びせた。獣が力を新たにして生まれ変わったことにより、強欲の化身を奉ずる者らは恐怖に身をすくめた。</p> </blockquote> <p>Netscape部門の閉鎖でMozillaという獣はいったん倒れたが、Firebird(=フェニックス)として灰より蘇った。文章内ではThunderbirdのイメージとも重なり、炎と雷を操る存在として描かれている。なお、ここで出てくるマモンもMicrosoftの暗喩である。</p><p>公式サイトにはないが、Wikipediaの記事には「8章20節」がある。Netscapeがブラウザ部門を再開し、Netscape Navigatorの新バージョンを社内で開発する可能性があることを社内メールで明らかにしたのが、2006年8月20日なのだそうだ。Netscape Navigator 9.0b1から9.0.0.6までに次の文章が掲載された。</p> <blockquote> <p>And thus the Creator looked upon the beast reborn and saw that it was good.</p><p>かくして主は獣の再誕をご覧になり、それを良きものとされた。</p> </blockquote> <p>Mozillaを作ったNetscapeが開発を再開したのでこうした文章になっているようだが、黙示文学というより旧約聖書『創世記』の天地創造のイメージだ。製品自体がMozillaプロジェクトから外れているだけでなく、about:mozillaの書きぶりとしても「異端」であり、公式サイトに掲載されていないのもそうした理由だと思われる。</p><p>MozillaにとってMozilla Foundationの創設に次いで節目となるのは、Firefox 1.0のリリースである。2004年11月9日のリリースを記念して、2008年1月、「11章9節(第10版)」が作られた(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=411352">Bug 411352</a>)。オープンソース化から10年が経ったので、「第10版」の表記がある。Firefox 3.0 Beta 3から20.0.1までなどに掲載されたのが、次の文章だ。</p> <blockquote> <p>Mammon slept. And the beast reborn spread over the earth and its numbers grew legion. And they proclaimed the times and sacrificed crops unto the fire, with the cunning of foxes. And they built a new world in their own image as promised by the sacred words, and spoke of the beast with their children. Mammon awoke, and lo! it was naught but a follower.</p><p>強欲の化身は眠りについた。獣の生まれ変わりは地に広がり、その数は増えて大群となった。それらは狐の抜け目なさをもって、時が満ちたことを宣言し、収穫物を捧げものとして火にくべた。それらは御言葉において約束されたとおり自らの思い描く新世界を作り上げ、子らに獣のことを語り伝えた。強欲の化身が目覚めたとき、見よ、それはただの模倣者と成り果てていた。</p> </blockquote> <p>この文章には多くの出来事が盛り込まれている。まず、マモンはMicrosoftを指しており、Internet Explorer 6から7までの開発期間が5年空いたことを指して、眠りについたと表現している。Microsoftが「眠っている」間にいわゆるWeb 2.0の時代になり、「目覚めた」ときにはイノベーターではなくなっていたというわけだ。</p><p>一方MozillaはSpread Firefoxというプロモーションサイトを起ち上げ、Mozillaマニフェストを公表し、about:mozillaニュースレターを発行した。FirefoxのサポーターたちはNew York Times紙に広告を載せ、Firefoxのロゴマークのミステリーサークルを作った。こうした様々な情報を文章に落とし込むスタイルは、その後も継承されている。代わりに、黙示文学的な預言の雰囲気は薄れていく。</p><p>Firefox OS 1.0がコードフリーズとなった2013年1月15日も、Mozillaにとって重要な時期であった。デスクトップからモバイルへと開発の重心が大きく傾いたからだ。この動きを反映して、「15章1節」が作られた(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=830767">Bug 830767</a>)。Firefox 21.0 Alpha 1から現在(56.0)まで掲載されているのが、次の文章である。</p> <blockquote> <p>The twins of Mammon quarrelled. Their warring plunged the world into a new darkness, and the beast abhorred the darkness. So it began to move swiftly, and grew more powerful, and went forth and multiplied. And the beasts brought fire and light to the darkness.</p><p>双子なる強欲の化身らは対立した。その争いは世界を新たなる闇に沈め、獣はその闇を忌み嫌った。そこで獣は素早く動き始め、力強さを増し、打って出てその数を増やした。そして獣らは闇に灯火をもたらした。</p> </blockquote> <p>双子のマモンとは、言うまでもなくAppleとGoogleのことである。両社が相争い、アプリ市場を寡占した。オープンなWebが損なわれることを嫌って、Mozillaは動き始め、Android版FirefoxやFirefox OSをリリースした。そうした出来事を描いているわけだが、残念ながらMozillaはその後、大幅な撤退を余儀なくなされた。</p><p>満を持しての反転攻勢は、Firefox Quantumから始まる。そのリリース予定日は2017年11月14日だ。というわけで、about:mozillaの「11章14節」は次のようになっている。</p> <blockquote> <p>The Beast adopted new raiment and studied the ways of Time and Space and Light and the Flow of energy through the Universe. From its studies, the Beast fashioned new structures from oxidised metal and proclaimed their glories. And the Beast's followers rejoiced, finding renewed purpose in these teachings.</p><p>獣は新たな衣服を身にまとい、時空と光、宇宙内のエネルギーの流れについて、それらのあり方を学んだ。学びにより獣は錆びた金属から新たな構造物を作り上げ、その栄光を宣言した。獣を奉ずる者らは教えの中に新たな目的を見出し歓喜した。</p> </blockquote> <p>時空はQuantum(量子)プロジェクトを指し、光はPhoton(光子)プロジェクトを指す。Photonの新UIにより、Firefoxは新たな衣服を身にまとうことになった。そして、Quantum CSSなど、Rust(錆)言語で書かれたコードがFirefoxに力を与えた。なお、スピードアップへの貢献度が高いQuantum Flowは、サブプロジェクトながら大きな扱いを受けている。</p><p>この一節が「預言」として現実のものとなるかどうか。それは神のみぞ知る、だろう。</p><p><div class="refList"><br /> <em>参考記事</em><br /> </p> <ul> <li><a href="http://end-of-file.net/storehouse/column/interpretation-book_of_mozilla/">about:mozilla 勝手に解釈 - EOF</a></li> <li><a href="http://norahmodel.exblog.jp/8133706/">The Book of Mozilla : norah'#</a></li> <li><a href="http://level.s69.xrea.com/mozilla/index.cgi?id=20080113_about-mozilla">The Book of Mozilla, 11.9: about:mozilla 更新 - えむもじら</a></li> <li><a href="http://forums.firehacks.org/l10n/viewtopic.php?t=2539">Mozilla L10N :: トピックを表示 - [wanted] Book of Mozilla, 11:9 (10th Edition)</a></li> <li><a href="http://d.hatena.ne.jp/himazublog/20080530/1212155178">Firefox日本語版にabout:mozillaで表示されるモジラの書の引用に改善の余地あり - himazu blog</a></li> </ul><p></div></p> Rockridge ブックマークからタブを開く際の隠し設定(Firefox 57以降) hatenablog://entry/8599973812306081289 2017-10-08T22:42:26+09:00 2017-10-22T07:34:24+09:00 Firefox Quantumは旧式の拡張機能がサポートされなくなるバージョンであり、本体の挙動をカスタマイズする拡張機能が動かなくなるケースも少なくないだろう。Mozillaも対策として、タブのコンテキストメニューにタブを複製する項目を追加したりしている。今回は、ブックマークからタブを開く際の挙動を変更する新設定を2つ紹介しておく。新設定はいずれもオプション画面からは変更することができない隠し設定だ。なのでまずはアドレスバーに"about:config"と打ち込んでページを開き、「動作保証対象外になります!」という警告が出たときは、「危険性を承知の上で使用する」をクリックして先へ進む。そして… <p>Firefox Quantumは旧式の拡張機能がサポートされなくなるバージョンであり、本体の挙動をカスタマイズする拡張機能が動かなくなるケースも少なくないだろう。Mozillaも対策として、タブのコンテキストメニューに<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=455722">タブを複製する</a>項目を追加したりしている。今回は、ブックマークからタブを開く際の挙動を変更する新設定を2つ紹介しておく。</p><p>新設定はいずれもオプション画面からは変更することができない隠し設定だ。なのでまずはアドレスバーに&quot;about:config&quot;と打ち込んでページを開き、「動作保証対象外になります!」という警告が出たときは、「危険性を承知の上で使用する」をクリックして先へ進む。そして、検索ボックスに以下の設定名を入力してみよう。</p><p>1つ目の設定は、<strong>browser.tabs.loadBookmarksInTabs</strong>。これをtrueに変更すると、ブックマークされたページを常に新しいタブで開くことができる(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=658245">Bug 658245</a>)。うっかり現在のタブを上書きしてしまうことを防げるわけだ。ただし、本記事執筆現在、ブックマークメニューとブックマークサイドバーでは正常に動作するが、メニューパネルのブラウジングライブラリーからページを開いた場合は挙動がおかしい。</p><p>2つ目の設定は、<strong>browser.bookmarks.openInTabClosesMenu</strong>。これをfalseに変更すると、ブックマークの項目を中ボタンクリックするかCtrlキーを押しながらクリックした場合、ページを開いた後もブックマークが閉じなくなる(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=260611">Bug 260611</a>)。フォルダ内の項目を順次開いていくときなどに便利だろう。</p><p><figure class="figure-image figure-image-fotolife"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171008/20171008222150.png" alt="f:id:Rockridge:20171008222150p:plain:w619" title="f:id:Rockridge:20171008222150p:plain:w619" class="hatena-fotolife" style="width:619px" itemprop="image"></span><figcaption>ページを開いた後もブックマークが閉じない</figcaption></figure></p> Rockridge Firefox Quantum雑感 hatenablog://entry/8599973812303503108 2017-10-01T23:10:17+09:00 2017-10-22T07:27:21+09:00 "Firefox Quantum"という名称 Mozillaの公式ブログその他を読むとFirefox QuantumはFirefox 57「だけ」の別名に見えるが、実際には数バージョンにわたって使用される名称だ。Photon UIのブラッシュアップはFirefox 59の開発サイクルが終わるまで続くという話があるので、Firefox 60からは元通り数字で呼ばれるんじゃないだろうか。Firefox 57は、Mozilla Corp.の社運を賭けたといっても過言ではないくらい大きな節目のバージョンになるので、盛り上げるために呼び名を工夫したいのはわかる。が、Quantumプロジェクトの達成度から… <div class="section"> <h4>&quot;Firefox Quantum&quot;という名称</h4> <p>Mozillaの公式ブログその他を読むとFirefox QuantumはFirefox 57「だけ」の別名に見えるが、実際には<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1398319#c1">数バージョンにわたって使用される</a>名称だ。<a href="https://mail.mozilla.org/pipermail/photon-dev/2017-September/000090.html">Photon UIのブラッシュアップ</a>はFirefox 59の開発サイクルが終わるまで続くという話があるので、Firefox 60からは元通り数字で呼ばれるんじゃないだろうか。</p><p>Firefox 57は、Mozilla Corp.の社運を賭けたといっても過言ではないくらい大きな節目のバージョンになるので、盛り上げるために呼び名を工夫したいのはわかる。が、Quantumプロジェクトの達成度からいうと中途半端な印象だ。今できる高速化を詰め込んだQuantum Flowが成功したので、格好はついたものの、Firefox 57の時点で有効化されたのはQuantum CompositorとQuantum CSSまで。それにQuantum CSSが真価を発揮するのはこれからだ。仮にFirefox 60までQuantumの名前を引っ張るにせよ、Quantum DOMは追加できてもQuantum Renderは間に合うかどうか。</p> </div> <div class="section"> <h4>高速化と応答性</h4> <p>いちおうここでもFirefox 57のことをFirefox Quantumと呼ぶことにするが、Firefox Quantumはたしかに速い。Developer EditionやBeta版を試用したユーザーからの評判もいいようだ。ただ、速さは体感的なものでもある。応答性の向上なども感覚に影響を及ぼしているのは間違いない。</p><p>Quantum Flowでは速度低下の原因を詳しく分析して、丹念に取り除いた。Firefox 55から効果が出始め、Firefox QuantumではSpeedometer v2ベンチマークにおけるChromeとの差が20%以内にまで縮まった。実環境を反映する度合いが高いとGoogleがお墨付きを与えたベンチマークで、ついにChromeの背中を捉えたのだ。Quantum CSSはGeckoのスタイルシステムからパフォーマンスが落ちないようにしながら、うまくはまった場合は高い効果を発揮する。そのほか、Windows版では<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1385051">Advanced Layers</a>と呼ばれるDirect3D 11ベースのcompositorが有効化されている。できるだけ多くのレンダリング処理を1回の描画で済ませることにより、CPU/GPUリソースの無駄遣いをなくすという。</p><p>こうした高速化に加えて、Mozillaが従来から取り組んできた成果がFirefox Quantumで全面的に発揮されることになる。たとえばe10sだ。旧式アドオンを排除したことで、e10sが無効になる要素がなくなった。今のe10sはcontentプロセスが4つに増えたe10s-multiである。そして、Quantum Compositorが独立したプロセスで動く中、Async Pan/Zoom(APZ)が<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1376525">キーボードによるスクロール</a>を含めて効いてくる。e10s無効の環境から移行すれば、応答性の違いは顕著だ。1年前にMozillaが、e10sでふつうのWebサイトは400%、複雑なWebサイトは700%応答性が向上すると<a href="https://www.cnet.com/news/mozilla-giving-half-of-firefox-users-a-snappier-browser-with-electrolysis-project/">言い出した</a>ときは、さすがに盛りすぎだろうと思ったが、今の状況なら400%アップもありえそうだ。</p><p>あと、最近Developer Edition/Beta版をインストールしたユーザーは、ほとんどがスタブインストーラを使っているはずだ。大多数を占めるWindows環境では、これで知らず知らずのうちに64bit化している。Mozillaは64bit版に関し、安定性は高まるが速度は変わらないというスタンスだが、システム要件ぎりぎりまでを念頭に置くからそうなるのであって、多くの環境では若干処理が高速になっていると思う。</p> </div> <div class="section"> <h4>新しいUI</h4> <p>Photonの新デザインはUIの隅々にまで及んでいるが、ぱっと目につくのはタブが四角くなったのと、タブバーの背景色の変更、それにメニューパネルが文字中心になったことだろうか。ロケーションバー改めアドレスバーで「…」をクリックすると、ページアクションメニューが表示されるようになっているのだが、ちょっと気付きづらいか。それよりも、ツアー画面のオーバーレイ表示がうるさいかもしれない。これでもスキップがかなりしやすくなったほうだ。開発者たちがNightlyで試行錯誤し始めたころなんか、恒久的にオフにする方法が見つけにくくて、嫌がらせかと思うほどだった。</p><p>Mozillaはメニューパネルを一切いじらせない方針だ。項目の追加、削除、並び替えはできない。拡張機能を使っても駄目だ。その代わり、ツールバーのカスタマイズは柔軟にできるようにした。ツールバーに常時置いておくのはあれだが、無効化もしたくない拡張機能のアイコンは、まとめてオーバーフローパネルに放り込んでおけるので便利だ。一方、ダウンロードを始めるとボタンがツールバーに突然出てくる<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1397447">仕様に変わった</a>点は、異論もありそうである。</p> </div> <div class="section"> <h4>WebExtensions限定化</h4> <p>旧式アドオンを全部捨てるのは相当な賭けに思えたが、案外Mozillaは勝てるかもしれない。理由は簡単で、Firefox Quantumが速くて軽いからだ。他にあんまりメリットがなくて拡張機能が使えなくなりますでは、ふざけるなという反応になるだろうが、今までのバージョンより圧倒的に速く、軽くなるなら話は別だ。しかも、何でもありだったXULベースの旧式拡張機能に比べると、WebExtensionsベースの拡張機能は重くなりにくいし、今のところWindows版のみだが、<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1357486">まとめて1つの独立したプロセス</a>を割り当てられるので、本体を巻き込んでクラッシュする可能性も大幅に低下している。</p><p>Chromeの拡張機能APIを取り込んだことで制約が大きくなった反面、移植は簡単になり、開発者にとっての敷居も下がった。Mozilla Add-ons(AMO)には日々新しい拡張機能が追加されていて、WebExtensionsの割合も増えてきた。現時点でこれだから、Firefox Quantumのリリース前後にはもっと賑わうだろう。しばらくはダイナミックにランキングが入れ替わりそうだ。Chromeの拡張機能を移植したことで、Firefoxユーザーの間で火がつき、Chromeユーザーにも人気が出るといったサクセスストーリーが生まれることを期待したい。</p> </div> <div class="section"> <h4>最後に</h4> <p>Chrome一人勝ちの状況の中、勝負はこれからだとばかりにFirefox Quantumが出てきた。Mozillaが自画自賛するように、出来は素晴らしい。その上Quantumプロジェクトはまだ先がある。本命はQuantum Renderで、これにWebAssemblyの最適化を合わせると、ゲームプラットフォームとしてのステージが一段上がるはず。旧式の拡張機能とともに捨てられる技術的負債もあるので、Firefoxの高速化は続く。これでシェアも回復してくれるといいんだが。</p><p><figure class="figure-image figure-image-fotolife"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20171001/20171001221145.jpg" alt="f:id:Rockridge:20171001221145j:plain:w400" title="f:id:Rockridge:20171001221145j:plain:w400" class="hatena-fotolife" style="width:400px" itemprop="image"></span><figcaption>素晴らしきFirefox</figcaption></figure></p> </div> Rockridge Firefox 56で設定画面を改編 個別設定の検索も可能に hatenablog://entry/8599973812301074979 2017-09-24T20:39:20+09:00 2017-11-04T15:58:47+09:00 Firefox 56では「オプション」と呼ばれる設定画面(about:preferences)が大幅に変更される。従来8つあったカテゴリーが4つに再編され、これに伴って項目もあちこちに移動しているのだ(Bug 1365133)。2015年5月のFirefox 38で設定画面がタブ化された際も、その基本的な編成は変わることがなかったが、今回は全面的な見直しが行われている。また、1カテゴリー内の項目数が増えると目当ての設定を探しにくいという問題に対処するため、検索機能も付いた(Bug 1353954)。設定画面を開くと右上のページ内検索ボックスにフォーカスが当たり、ページのスクロールにも検索ボック… <p>Firefox 56では「オプション」と呼ばれる設定画面(about:preferences)が大幅に変更される。従来8つあったカテゴリーが4つに再編され、これに伴って項目もあちこちに移動しているのだ(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1365133">Bug 1365133</a>)。2015年5月のFirefox 38で設定画面がタブ化された際も、その基本的な編成は変わることがなかったが、今回は全面的な見直しが行われている。</p><p>また、1カテゴリー内の項目数が増えると目当ての設定を探しにくいという問題に対処するため、検索機能も付いた(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1353954">Bug 1353954</a>)。設定画面を開くと右上のページ内検索ボックスに<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1374852">フォーカスが当たり</a>、ページのスクロールにも検索ボックスは<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1377009">追従する</a>。</p><p>どのようにカテゴリーがまとめられ、項目が移動したのか、大まかに見ておこう。Firefox 55までの設定画面は、以下のようなカテゴリーの編成と項目のまとまりになっていた。</p> <ul> <li>一般 <ul> <li>起動</li> <li>ダウンロード</li> <li>タブグループ</li> <li>パフォーマンス</li> </ul></li> <li>検索 <ul> <li>既定の検索エンジン</li> <li>ワンクリック検索エンジン</li> </ul></li> <li>コンテンツ <ul> <li>DRMコンテンツ</li> <li>通知</li> <li>ポップアップ</li> <li>フォントと配色</li> <li>言語</li> </ul></li> <li>プログラム</li> <li>プライバシー <ul> <li>トラッキング(行動追跡)</li> <li>履歴</li> <li>ロケーションバー</li> </ul></li> <li>セキュリティ <ul> <li>一般</li> <li>ログイン情報</li> </ul></li> <li>Sync <ul> <li>Firefoxアカウント</li> <li>すべての端末を同期する</li> <li>端末名</li> </ul></li> <li>詳細 <ul> <li>一般 <ul> <li>アクセシビリティ</li> <li>ブラウズ</li> </ul></li> <li>データの選択</li> <li>ネットワーク <ul> <li>接続</li> <li>キャッシュされたウェブページ</li> <li>オフラインウェブページとユーザーデータ</li> </ul></li> <li>更新 <ul> <li>Firefoxの更新</li> <li>次のソフトウェアを自動的に更新する</li> </ul></li> <li>証明書 <ul> <li>要求</li> </ul></li> </ul></li> </ul><p>これに対し、Firefox 56では次のように変わっている。</p> <ul> <li>一般 <ul> <li>一般 <ul> <li>起動</li> <li>タブグループ</li> </ul></li> <li>言語と外観 <ul> <li>フォントと配色</li> <li>言語</li> </ul></li> <li>ファイルとプログラム <ul> <li>ダウンロード</li> <li>プログラム</li> <li>デジタル著作権管理(DRM)コンテンツ</li> </ul></li> <li>Firefoxの更新</li> <li>パフォーマンス</li> <li>ブラウズ</li> <li>ネットワークプロキシ</li> </ul></li> <li>検索 <ul> <li>既定の検索エンジン</li> <li>ワンクリック検索エンジン</li> </ul></li> <li>プライバシーとセキュリティ <ul> <li>ブラウザープライバシー <ul> <li>フォームとパスワード</li> <li>履歴</li> <li>アドレスバー</li> <li>キャッシュされたウェブページ</li> <li>トラッキング保護</li> </ul></li> <li>許可設定</li> <li>Firefoxのデータ収集と利用について</li> <li>セキュリティ <ul> <li>フィッシング保護</li> <li>証明書</li> <li>オフラインウェブページとユーザーデータ</li> </ul></li> </ul></li> <li>Firefoxアカウント <ul> <li>Firefoxアカウント</li> <li>Sync設定</li> <li>端末名</li> </ul></li> </ul><p>2つを比べてみると、〔検索〕と〔Sync〕のカテゴリーは改編後もほぼそのまま残っている。そして、〔プライバシー〕と〔セキュリティ〕が統合されている点もわかりやすい。つまり、今回の改編は、残る4カテゴリーを1つにまとめて並べ替えた点が大きい。</p><p>仕様書の<a href="https://mozilla.invisionapp.com/share/P4ACQT1E3#/screens/217167649">リリースノート</a>によれば、2017年6月にバージョンが1.3から2に飛んでおり、この時点でデザインが練り直されている。新デザインは「コンテンツ戦略とユーザーテストの結果」に基づいて決定されたという。筆者の理解だと、Mozillaはユーザーの使いやすさに配慮しつつも、アピールしたい箇所はカテゴリーのまま残したのだ。〔プライバシーとセキュリティ〕と並んで、〔検索〕と〔Firefoxアカウント〕が独立のカテゴリーになっている点は興味深い。将来的に項目を追加する予定があるからこそ、あえてそうなっているように思える。</p><p>ちなみに、次のFirefox 57の設定画面では、Photonの新UIに合わせて<a href="https://mozilla.invisionapp.com/share/X8BGCX9PD#/screens/244673481">ビジュアル面の改修が実施される</a>ほか、設定の一部も変更される。レスポンシブ化により、表示領域が狭いときはカテゴリーがアイコンのみで表示されるようになる点もポイントだ。</p><p><em>(17/11/04追記)</em><br>最近公開された<a href="https://medium.com/firefox-ux/whats-new-in-firefox-preferences-54391f92971a">What’s new in Firefox Preferences – Firefox User Experience – Medium</a>では、「ユーザーテストの結果」が詳しく紹介されている。記事によると、1.〔プライバシー〕と〔セキュリティ〕はまとめるのがよい、2.〔一般〕は必要だが〔詳細〕と同時にあると混乱を招く、3.アドレスバーの表示内容の制御などに関する設定はプライバシー関連と位置づけたほうが理解されやすい、4.〔Sync〕はカテゴリー名としてわかりづらいという知見が得られたそうだ。改編後の設定画面では、これらの知見が反映されていることがわかる。</p> Rockridge Firefox 55で刷新されたインストールプロセス Firefox 57でさらに改善へ hatenablog://entry/8599973812299310918 2017-09-18T23:52:57+09:00 2017-09-18T23:52:57+09:00 Firefoxを常用していると気付きにくいが、Firefox 55のリリースに伴ってMozillaはユーザーのインストールプロセスを刷新した。ここでいうインストールプロセスとは、ユーザーがデスクトップ版FirefoxのダウンロードページをクリックしてからFirefoxの初回起動が完了するまでを指す。以下の動画は、Windows版Chromeを使ってダウンロードページにアクセスしたという想定で、新プロセスについて解説したものだ。www.youtube.com従来のプロセスにおける問題点は、February 2017 Onboarding Test – Verdi@Mozillaに掲載された別の動… <p>Firefoxを常用していると気付きにくいが、Firefox 55のリリースに伴ってMozillaはユーザーのインストールプロセスを刷新した。ここでいうインストールプロセスとは、ユーザーがデスクトップ版FirefoxのダウンロードページをクリックしてからFirefoxの初回起動が完了するまでを指す。以下の動画は、Windows版Chromeを使ってダウンロードページにアクセスしたという想定で、新プロセスについて解説したものだ。</p><p><iframe width="480" height="270" src="https://www.youtube.com/embed/gadcAzdoIEA?feature=oembed" frameborder="0" allowfullscreen></iframe><cite class="hatena-citation"><a href="https://www.youtube.com/watch?v=gadcAzdoIEA">www.youtube.com</a></cite></p><p>従来のプロセスにおける問題点は、<a href="https://mozilla.michaelverdi.com/february-2017-onboarding-test/">February 2017 Onboarding Test – Verdi@Mozilla</a>に掲載された別の動画で指摘されている。その内容をまとめると、次のようになる。1.ブラウジング開始までに必要なクリック数が多すぎる。2.インストーラやダウンロードページの工夫がインストール体験の向上に結びついていない。3.まっさらな状態でインストールされるため、Firefoxに乗り換えたユーザーが訪れたいWebサイトに直ちにたどり着けない。</p><p>問題1を解決するため、Mozillaはインストール完了に必要なクリック数を減らした新インストーラを開発した(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1365998">Bug 1365998</a>)。ただし、スタブ(軽量)インストーラが対象で、フルインストーラは従来通りである。併せて、ユーザーアカウント制御(UAC)のダイアログで特権の昇格が許可されない場合も、インストーラを終了させず、可能な限りインストールを続行するようにした(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1350974">Bug 1350974</a>)。また、Firefoxの初回起動時には、既定のブラウザに設定するかどうかを尋ねるプロンプトを表示しないようにした(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1367073">Bug 1367073</a>)。<a href="#f-b46cc5ce" name="fn-b46cc5ce" title="プロンプトは2回目の起動時に表示され、表示回数は3回に限定される。Firefox 43に実装された機能だが、今回初めてリリース版で有効化された。">*1</a></p><p>問題2を解決するため、新インストーラは余分なメッセージを表示しないようになっている。ダウンロードページ側にも工夫が施され、ファーストビューに必要な内容が集約されている。画面が夜の風景なのは、Firefoxの初回起動時に表示されるページ(以下ファーストラン)で太陽が昇る演出になっているためだ。なお、<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1366763">新インストーラのアイコン</a>も、インストール後にFirefoxのアイコンがデスクトップに現れることを意識して、緑の箱の中からFirefoxのアイコンが顔をのぞかせた絵柄に変更されている。</p><p><figure class="figure-image figure-image-fotolife"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20170918/20170918211848.png" alt="f:id:Rockridge:20170918211848p:plain:w379" title="f:id:Rockridge:20170918211848p:plain:w379" class="hatena-fotolife" style="width:379px" itemprop="image"></span><figcaption>ファーストビューに必要な内容を集約</figcaption></figure></p><p>問題2に関連して、ファーストランに表示されるFirefoxアカウント関係のメッセージも改良された。従来はアカウントの作成を促すようになっていたのだが、作成しないとFirefoxを利用できないと誤解するユーザーもいたそうだ。そこで、代わりにログイン画面を出しつつ、アカウントを作成した場合の具体的なメリットを提示するようにした。</p><p>他方、問題3の解決は今後に持ち越しとなった。Firefoxのホームタブは検索サービスの提供がメインで、新規タブもMozilla関連のWebサイトしか登録されていない。Firefoxに乗り換えたユーザーが従来のブラウザの履歴やブックマークをインポートしてくれれば、新規タブによく使うページを表示できるのだが、初回起動前に設定移行ウィザードを出す現在のやり方では、効果が薄いことが判明している。ユーザーはとにかくFirefoxを起動させたいので、処理を後回しにしてしまうのだ。そこで、インポートを自動化する計画だったのだが、パフォーマンスに悪影響が出るため採用は<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1381714">見送られた</a>。</p><p>Mozillaはインストールプロセス刷新を今回実行するまでに、試行錯誤を重ねている。<a href="https://mozilla.michaelverdi.com/new-download-and-install-flow-for-firefox-55/">New download and install flow for Firefox 55 – Verdi@Mozilla</a>が事前テストの結果について言及しており、それによると問題1・2を解決した新プロセスは4つの点で成功を収めたという。</p> <ol> <li>インストーラの修正でインストール数が8%増加。</li> <li>インストーラ以外の修正でFirefoxの初回起動を完了したユーザーが2.4%増加。</li> <li>新プロセスに対するユーザーのレーティングは従来と同じ。積極的に評価するユーザーも。</li> <li>ファーストランの修正でFirefox Syncに2台目のデバイスを接続するユーザーが14.8%増加。</li> </ol><p>新プロセスのレーティングが変わっていないのに成功と評価する理由が上記記事には記載されていないが、おそらくデメリットが目立っていないという趣旨だろう。新インストーラはオプション設定に移行するボタンや、インストール処理をキャンセルするボタンも省かれている。前者はフルインストーラで代替できるのでよいとしても、後者は誤クリックによってインストールが開始された場合にユーザーはアンインストールを余儀なくされることになる。その意味で、かなり割り切った仕様と言えよう。</p><p>Mozillaは、Firefox 57で手動インポートの手順を改善し、積み残された問題3の解決を図る。初期設定でホームタブと新規タブが統一され、利用頻度の高い「トップサイト」や直近の訪問・ブックマーク履歴を基にした「ハイライト」が表示されることを踏まえて、それらのタブに他のブラウザからのインポートを促すメッセージが表示されるようになる(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1361294">Bug 1361294</a>)。ユーザーが「インポートする」を選んだ場合に設定移行ウィザードが出るのは従来通りだが、移行が完了すると当然ホームタブ・新規タブの内容に反映される。これに対し、ユーザーがインポートを拒否するか、3活動日にわたって何も選択されなかったときは、メッセージは表示されなくなるという<a href="https://mozilla.invisionapp.com/share/B5CQAT17W#/screens/245309456_Manual_Import">仕様</a>だ。なお、この措置に伴ってFirefoxの初回起動時に設定移行ウィザードは表示されなくなる。</p><p>以上のほか、Firefox 57のスタブインストーラは、3バージョン以上古いFirefoxのインストールを検出するか、Firefoxがインストールされていない状態で既存のプロファイルを検出した場合、プロファイルのクリーンアップを行う選択肢を有効化した状態で示すようになる(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1369255">Bug 1369255</a>)。設定が初期化されるうえアドオンも削除されるので、インストール時には注意が必要になるだろう。</p><p><figure class="figure-image figure-image-fotolife"><div class="images-row mceNonEditable"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20170918/20170918224921.png" alt="f:id:Rockridge:20170918224921p:plain" title="f:id:Rockridge:20170918224921p:plain" class="hatena-fotolife" itemprop="image"></span><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/R/Rockridge/20170918/20170918224941.png" alt="f:id:Rockridge:20170918224941p:plain" title="f:id:Rockridge:20170918224941p:plain" class="hatena-fotolife" itemprop="image"></span></div><figcaption>左:古いFirefoxを検出した場合 右:既存のプロファイルを検出した場合</figcaption></figure></p> <div class="footnote"> <p class="footnote"><a href="#fn-b46cc5ce" name="f-b46cc5ce" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">プロンプトは2回目の起動時に表示され、表示回数は3回に限定される。<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1191250">Firefox 43に実装された機能</a>だが、今回初めてリリース版で有効化された。</span></p> </div> Rockridge