Windows版Firefox 57で既定の日本語フォントをメイリオに変更

Windows版Firefox 57では、対象言語が日本語の場合におけるゴシック体（Sans-serif）の既定のフォントが「メイリオ」に、明朝体（Serif）の既定のフォントが「游明朝」に変更される（Bug 1354004）。これまで、ゴシック体は「ＭＳ Ｐゴシック」、明朝体は「ＭＳ Ｐ明朝」が既定のフォントであり、日本語版Firefoxでは初期設定で「ＭＳ Ｐゴシック」がWebページの表示に使用されるフォントとなっていた。Firefox 57からはこの表示フォントがメイリオに切り替わる。*1

mozilla.dev.platformの"Intent to ship: Changing default Japanese fonts to modern fonts"スレッドでは、モダンなフォントに切り替えるにあたって、「游ゴシック」ではなくメイリオを選んだ理由が説明されている。メイリオは、システム言語が日本語であればFirefoxがサポートするWindows 7以降で広く使えるし、Google ChromeやMicrosoft Edgeが既定のフォントとして採用済みなので、ブラウザ間の互換性も高まる。これに対し游ゴシックは、表示された文字が細すぎて読みにくい。そうした検討の結果、メイリオに軍配が上がった。

メイリオを標準で採用した場合、CSSのfont-styleで"italic"や"oblique"を指定しても、イタリック体や斜体にならないという問題があった。Microsoftによれば、これは仕様である。

メイリオ フォントの斜体スタイルは、英語 (半角のアルファベット、数字、記号) のみ対応しています。このためメイリオ フォントを使用している場合、フォント スタイルを斜体に変更すると、半角の英語のみ斜体スタイルが適用されます。

https://support.microsoft.com/ja-jp/help/929886

しかし、Mozillaは処理を工夫することで、この問題を回避した（Bug 1351332）。たとえばem要素が指定されている場合も、メイリオフォントが指定された文字は斜体になる。こうした工夫はChromeやEdgeには見られないものだ。ちなみに、該当する修正はFirefox 55リリース版にも入っている。

Firefox 57はPhotonプロジェクトの新デザインが披露される場なので、アップデート後に再起動すると見た目が大きく変わっているわけだが、さらに既定のフォントが変わることで、Webページを表示した際に受ける印象も違ってくることだろう。

なお、等幅（Monospace）の既定のフォントは従来通り「ＭＳ ゴシック」が用いられる。また、今回の措置は将来リリースされるThunderbird 59にも影響し、HTMLメールはメイリオで表示されるようになる。

*1:Firefox 55以降のNightlyチャンネルやDeveloper Editionでは変更済み（Bug 548311）。

Firefox 57で4年ぶりにロゴを更新（追記あり）

オーストリアのsoeren-hentzschel.atが"So sieht das neue Logo von Firefox und Firefox Klar aus"という記事で、Firefoxのロゴ更新を報じている。2017年11月14日（米国時間）にリリース予定のFirefox 57で実施され、既にAndroid版Nightlyには新ロゴが組み込まれているとのこと。Mozilla Corp.でDirector, Firefox User Experienceを務めるMadhava Enros氏もFirefox 57のアイコンが変更される旨のツイートをしており、間違いなさそうだ。

現行のロゴは2013年8月にFirefox 23に実装された4代目のものである。"A New Firefox Logo for a New Firefox Era | about:pixels"によれば、低解像度の小さなスクリーンでも映えるようにデザインをシンプルにしたそうだが、今度の5代目はさらにシンプルになっている。色合いも思い切って変えてきた。

新ロゴはFirefox Nightly 57に実装されたもの*1と色違いのデザインだ。そして、Firefox Focusも同様に色違いのデザインを採用することになっている。Firefox 57で一斉にロゴを変更する計画が存在することがうかがえる。

I hope you all enjoy our new logo ;) pic.twitter.com/tDYu4ssbUG

— Firefox Nightly (@FirefoxNightly) 2017年8月4日

そうした目で"Photon Engineering Newsletter #11 | Dolske's blog"を見直してみると、新ロゴは小規模なチームがかなりの期間をかけてデザインしたものであるとわかる。Mozilla Corp.の内部でさえ、最近まで一部の人にしか知られていなかったようだ。

（17/09/16追記）
更新されたロゴが実装された（Bug 1399691）。また、Firefox Developer Editionのアイコンも新しくなった（Bug 1399717）。

左：Firefoxの新ロゴ 右：Firefox Developer Editionの新ロゴ

*1:デスクトップ版：Bug 1387254、Android版：Bug 1388291

Firefox 57のメニューパネルにおいてサブメニューはどのように表示されるべきか

2017年11月14日（米国時間）にリリース予定のFirefox 57では、Photonプロジェクトの成果である新ユーザーインターフェイス（UI）が導入される。新UIはいちはやくNightlyチャンネルに投入されており、Firefox Nightly 56ではメニューパネルが新しいものに置き換えられた（Bug 1372309）。

新しいメニューパネル

新メニューパネルの項目の一部には、「＞」の記号が表示されている。これは、サブメニューが存在することを示すアイコンだ。「＞」アイコン付きの項目をクリックすると、サブメニューが右側からスライドしてきて、覆い被さるようにメインメニューと入れ替わる仕様になっている。本記事では、この方式を「スライド式」と呼ぶことにする。

サブメニューのWeb Developerが表示される様子

スライド式では、項目の上にマウスカーソルを置いてもサブメニューは表示されない。他方、OSの標準的な挙動はマウスカーソルのホバーでサブメニューが表示されるというもので、Chromeなどもそうなっている。現行のFirefoxでもメニューバーのサブメニューはマウスカーソルのホバーで展開される。

新メニューパネルのサブメニュー表示にクリックが必要なことに対しては批判が強く、ホバーで展開されるようにすべきだとの声が上がっている（Bug 1366074、Bug 1373966）。だが、Mozillaはスライド式を維持する方針であり、登録されたバグはWONTFIX（対処せず）で処理された。

Mozillaの開発者たちの主張をまとめると、スライド式を採用しつつサブメニューをマウスカーソルのホバーで展開すると、意図せずサブメニューに遷移してしまうし、Chromeのようにサブメニューをメインメニューの外側に表示しようとすれば、コードの全面的な書き換えが必要になってFirefox 57に間に合わず、メニューの複数階層化も難しくなる。現行のFirefoxのUIでも既にスライド式は採用されている、といったところだ。

少し解説を加えよう。まず、スライド式とホバー表示の組み合わせは確かに相性が悪い。項目上にカーソルが一定時間とどまった場合にのみサブメニューを表示するとしても、意図しないサブメニューを表示してしまうケースの発生は避けられないだろう。そこからメインメニューに戻ろうとすれば、いったんメニューを閉じて開き直すか、サブメニュー上の「＜」アイコンのある項目にカーソルを合わせて待つことになる。こうした誤操作が起きないようにカーソルがとどまるべき時間を長く取ると、今度は正しい項目にカーソルを持っていったときに待たされ、ユーザーにモッサリとした印象を与えてしまう。

次に、新メニューパネルではサブメニューのそのまたサブメニューまであり、メニューの階層化が複数に及んでいる。たとえば、Libraryの項目からサブメニューに移行するとHistoryの項目があり、そこからさらにサブメニューに移行するとブラウジング履歴が表示されるといった具合だ。Chromeはサブメニューの項目を絞っているのでメインメニューの外側に表示しても問題ないが、Firefoxの新メニューパネルで同じことをやろうとすれば、開発ツールの項目のサブメニューや二段階目のサブメニューは画面からはみ出す可能性があるので、調整が必要となる。逆に、Chromeのようにサブメニューの項目を絞るとなれば、メニューの全面的な再編が不可欠だ。いずれにせよ、Firefox 57には間に合わなくなる。

Libraryサブメニューとその直下のHistory

最後に、現行のメニューパネルでも、たとえば履歴アイコンをクリックするとブラウジング履歴はスライド式で表示される。また、ブックマークサイドバーにおいてフォルダには「＞」のアイコンが表示されるものの、中身の展開にはクリックが求められる。メニューバーの挙動は上記のとおりChromeなどと同じだが、初期設定でメニューバーは隠されているので、重要度は落ちる。このように、UIの一貫性という意味ではむしろスライド式のほうに分がある。

問題があるとすれば、「＞」アイコンが利用者にホバー展開が可能との期待を抱かせる点だろう（Bug 1375770）。この点についてはMozillaのPhilipp Sackl氏がアイコンの微修正を示唆しており、Firefox 57のリリースまでに修正が加えられそうだ。

筆者は、「＞」アイコンに修正が加えられるのであればスライド式でよいと考えている。それよりも、新メニューパネルはカスタマイズが一切できない（項目の追加、削除、入替えができない）ことのほうが、よっぽど大きな問題ではないだろうか。

（17/09/15追記）
Bug 1375770はWONTFIX（対処せず）で処理され、Firefox 57のメニューパネルに「＞」アイコンはそのまま残ることになった。なお、追記にあたって、本文の画像にキャプションを付けた。

ワンクリックで以前のセッションを復元する（Firefox 56以降）

本記事執筆時点では初期設定で無効になっているが、以前のセッションを復元するボタンがFirefox Nightly 56に追加された。Firefoxの起動時にタブバー上にボタンが出現し、これをクリックするとセッションが復元される（Bug 1219725）。

この機能を有効化するためには、about:configの画面でbrowser.tabs.restorebuttonの設定をtrueに変更する。変更後にFirefoxを再起動してみると、タブバーの「＋」ボタンの隣に、"Restore Tabs From Last Time"というラベルのボタン（復元ボタン）が表示されているはずだ。このとき復元ボタンを押すとセッションが復元され、「＋」ボタンを押して新規タブを追加すると復元ボタンは消える。

若干の問題点もある。最後に開いていたタブのURLがホームページに設定したURLと一致する場合も復元を行おうとするし、セッション復元後もタブバー上にボタンの外枠が潰れた形で残ってしまう。「＋」ボタンと復元ボタンの位置が近すぎる点は、誤操作を誘発しかねない。

とはいえ、ワンクリックでセッションが復元されるのは確かに便利だ。本体終了時にセッション保存の要否をダイアログで尋ねられることもないし、拡張機能も入れなくていい。Firefox 56のリリース時に初期設定で有効化されていることを期待したい。

（17/07/02追記）
参考画像は新規プロファイルを用いているので、about:homeの最下段にセッション復元のアイコンがある。だが、ホームページの設定を変更してしまうとこのアイコンは使えない。また、Firefoxの起動直後はタブのある画面上部に意識が集中するため、その位置に復元ボタンを置くのは自然なUIといえる。

Add-on SDKのサポートがFirefox 59までに終了へ（追記あり）

MozillaのAndy McKay氏（Senior Engineering Manager）は、米国時間の2017年6月21日、mozilla.dev.platformの"Intent to unship: Add-on SDK and others"スレッドにおいて、Firefox 58または59で、本体からAdd-on SDKを削除するとアナウンスした（Bug 1371065）。同氏はWebExtensions推進の中心人物であり、今回のアナウンスもFirefox 57リリース版でWebExtensionsベースの拡張機能だけが有効となる措置を踏まえたものだ。

Add-ons/Firefox57 - MozillaWikiにおいて明らかにされているとおり、Firefox 57のリリース後も、Nightly（やDeveloper Edition）では、設定を変更すれば旧式の拡張機能を動作させることができる。Developer EditionがBeta版と共通のコードを使うようになったこともあり、Firefox 57のリリースに伴ってDeveloper Editionに乗り換え、当面は旧式の拡張機能を使い続けようと考えていたユーザーもいたのではないか。

今回のアナウンスは、そうした回避策が短期間しか通用しないことを明らかにした。Firefox本体からAdd-on SDKが削除されてしまえば、原則としてSDKベースの拡張機能は動作しなくなる。設定でどうにかできない分、影響は深刻といえる。理屈のうえでは、拡張機能が個別にSDKごとパッケージ化すれば大丈夫なのかもしれないが、SDK自体のメンテナンスが必要になるので現実的ではない。

おそらく、一番困るのはFirefox ESRを導入している企業ユーザーだろう。Firefox 59は次のESRの基盤となるから、ESR 52系列のサポートが終わるとAdd-on SDKベースの拡張機能が使えない環境に移行せざるを得なくなる。業務に支障が出る可能性もありそうだ。ただ、上記アナウンスによれば、スケジュールはまだ確定していないそうなので、反対意見が多くなれば、Add-on SDKの削除はFirefox 60に延期という話もあるかもしれない。

また、上記アナウンスによれば、「サポート対象外となった設定（configurations）のサポートをアドオンマネージャから削除する（Bug 1371064）」ことや、「一部のXPCOMサポートを廃止する（Bug 1347507）」ことも検討中だという。

どちらも曖昧な表現だが、前者のBug 1371064の依存関係を見ると、再起動を要するアドオンのサポート廃止が含まれる。明確な説明はないものの、ひょっとするとFirefox 59の段階でそこまで視野に入れているのかもしれない。仮にそうだとすれば、旧式の拡張機能は相当数が強制的に退場を余儀なくされるだろう。

（17/09/15追記）
Bug 1371065の修正により、Add-on SDKは早くもFirefox Nightly 57から削除された。Nightlyユーザーはもちろん、Developer Editionユーザーも、Firefox 57のリリースを待つことなくAdd-on SDKベースの拡張機能が使えなくなる。

（17/10/05追記）
Firefox 57でAdd-on SDKが削除されたことに関し、Incoming: Removal of the Add-on SDKとBug 1350646も参照。