Mozilla Flux

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

Firefox 49でChrome・Safariを基準に作成されたコンテンツの表示精度が向上

Firefox Web互換性

Firefox 49では、既存のコンテンツとの互換性を高めるため、-webkit-のベンダープレフィックス（以下「webkit接頭辞」）がついたCSSプロパティや属性を多数サポートしている。layout.css.prefixes.webkitが初期設定で有効化される（Bug 1259345）ことによるもので、ベータ版リリースノートには掲載されていないが、Chrome・Safariを基準に作成されたコンテンツの表示精度が向上するため、一般ユーザーにとっても重要な変更といえるだろう。

サポート対象となる具体的なプロパティや属性については、MDNのFirefox 49 for developersにまとめられている*1。が、初期設定で無効のものが混じっているなど若干煩雑なので、改めて整理しつつ列挙しておこう。

-webkit接頭辞がついていても動作するプロパティ

  1. -webkit-align-items
  2. -webkit-align-content
  3. -webkit-align-self
  4. -webkit-animation
  5. -webkit-animation-delay
  6. -webkit-animation-direction
  7. -webkit-animation-duration
  8. -webkit-animation-fill-mode
  9. -webkit-animation-iteration-count
  10. -webkit-animation-name
  11. -webkit-animation-play-state
  12. -webkit-animation-timing-function
  13. -webkit-backface-visibility
  14. -webkit-background-clip
  15. -webkit-background-origin
  16. -webkit-background-size
  17. -webkit-border-bottom-left-radius
  18. -webkit-border-bottom-right-radius
  19. -webkit-border-image
  20. -webkit-border-top-left-radius
  21. -webkit-border-top-right-radius
  22. -webkit-border-radius
  23. -webkit-box-shadow
  24. -webkit-filter
  25. -webkit-flex
  26. -webkit-flex-basis
  27. -webkit-flex-direction
  28. -webkit-flex-flow
  29. -webkit-flex-grow
  30. -webkit-flex-shrink
  31. -webkit-flex-wrap
  32. -webkit-justify-content
  33. -webkit-order
  34. -webkit-perspective
  35. -webkit-perspective-origin
  36. -webkit-text-size-adjust
  37. -webkit-transform
  38. -webkit-transform-origin
  39. -webkit-transform-style
  40. -webkit-transition
  41. -webkit-transition-delay
  42. -webkit-transition-duration
  43. -webkit-transition-property
  44. -webkit-transition-timing-function
  45. -webkit-user-select

同等の接頭辞つきプロパティに紐づけられてサポートされるプロパティ

  1. -webkit-box-flex
  2. -webkit-box-ordinal-group
  3. -webkit-box-orient
  4. -webkit-box-align
  5. -webkit-box-pack

同等の接頭辞つきプロパティに紐づけられずにサポートされるプロパティ

  1. -webkit-text-fill-color
  2. -webkit-text-stroke-color
  3. -webkit-text-stroke-width
  4. -webkit-text-stroke

CSSグラデーション関係

  1. -webkit-linear-gradient()、-webkit-radial-gradient()、-webkit-repeating-linear-gradient()および-webkit-repeating-radial-gradient()の各関数は接頭辞なしの同等物に紐づけ
  2. 旧式の-webkit-gradientをサポートし、正規のグラデーションに変換

displayプロパティの値を変換

  1. -webkit-boxを-moz-boxに変換
  2. -webkit-flexをflexに変換
  3. -webkit-inline-boxを-moz-inline-boxに変換
  4. -webkit-inline-flexを-moz-inline-flexに変換

その他

  1. WebKitCSSMatrixインターフェイスをDOMMatrixの別名（エイリアス）として設定
  2. メディアクエリのメディア特性に-webkit-transform-3dを追加


（16/09/22追記）
本記事の掲載後、Firefox 49のリリースに合わせて、Firefox 49 fixes sites designed with WebKit in mind, and more ★ Mozilla Hacks – the Web developer blog（和訳：Webkit を念頭に作成されたサイトで起きるブラウザ互換性問題に対する Firefox の対応 | Mozilla Japan ブログ）が公開されている。

*1:該当するBugzilla＠Mozillaのバグについては、mozilla.dev.platformのスレッド"Update on WebKit prefix support in Gecko."が詳しい。

Firefox 48でスマートロケーションバーのデザインが変更 元に戻す設定はなし

Firefox UI変更

Firefox 48のリリースが目前に迫っている。このバージョンの目玉となるのがマルチプロセス機能（e10s）の有効化、Mozillaが推しているのがダウンロード保護の強化という事情もあって、あまり日が当たらないものの、使い勝手の観点からスマートロケーションバーのデザイン変更（Bug 1181078）は見逃せない。

f:id:Rockridge:20160803000355p:plain

Firefox 47までと見比べてみれば一目瞭然だ。これまで、ロケーションバーに文字を打ち込むと、ドロップダウンメニューに表示される候補はタイトルとURLの2行で表示されていた。Firefox 48の新デザインでは、これが1行にまとめて表示される。また、表示される候補の数が6個から10個へと増え（Bug 1195054）、各候補中の入力文字にヒットした箇所が太字で強調表示されるようになった（Bug 1273943）。

f:id:Rockridge:20160803001010p:plain

Beta版のリリースノートであっさりした記述になっていたためか、海外ではredditのスレッドにある程度コメントが集まっていたのに対し、国内ではかろうじて窓の杜が言及している程度だ。しかし、ロケーションバーを使用しないユーザーはかなり少数だろうし、ふつうは頻繁に使う機能のはずなので、リリース直後からそれなりに反響を呼んでもおかしくない。否定的な反響のほうが大きくなる可能性すらあるだろう。現に開発版の段階で、1行にまとめると見づらいとか、ドロップダウンメニューが大きすぎるといった批判が出ているからだ。

目立つ変更であっても、元に戻す設定がどこかに設けられていれば批判の矛先をかわすこともできるのだが、あいにく今回の変更は不可逆的なもので、設定で元に戻すことはできない。Australisが導入された際にClassic Theme Restorerが出たように、元のデザインに戻す拡張機能が出てこない限り、ユーザーとしては新デザインに慣れるしかない。

速報：Firefox 49本体からFirefox Helloが削除

Firefox サポート関連

Firefox 49本体からFirefox Helloが削除されたことが判明した（Bug 1287827）。Mozilla plans to remove Hello from Firefox 49 - gHacks Tech Newsで既報だが、該当バグのステータスはRESOLVED FIXEDとなっており、確定事項だ。米国時間の2016年7月19日時点で削除は決定されていたようだが、7月29日の午前3時過ぎまでBugzilla＠Mozillaで秘匿指定がされていたため、情報が伏せられていた。

Firefox HelloはWebRTCの技術を利用してブラウザ内でビデオ（音声）通話を行うシステムで、相手方とWebページを共有して議論することに重点を置き、サインインなどの手続きがいらないという特徴を持つ。MozillaはスペインTelefónica社傘下の米TokBox社と提携し、Firefox Helloのプラットフォームとして同社のOpenTokを採用しており、その動作にはプラグインを必要としない。

2014年5月末にNightlyチャンネルでテストが始まり、ある時期までLoopのコード名で呼ばれていた。当初のコンセプトは、クロスプラットフォームな動画チャットアプリであり、ブラウザオンリーでWebRTCが有効なChromeやOperaとも通話できる点に目新しさがあった。デフォルトでツールバーにボタンが置かれるなど、Mozillaが一時期Firefox Helloを強く推していたのは間違いない。ユーザーからのフィードバックを受けて通話プロセスを簡略化したのも、利用を促進したいと思えばこそだ。

Firefox HelloはFirefox 35で正式にリリースされ、アクティブなタブまたはウィンドウの共有機能がFirefox 38.0.5で導入されている。Firefox 39では、ビデオ通話を開始するためのリンクを、本体に統合されたソーシャルサービスを通じて共有できるようになった。

もっとも、MozillaはFirefox 45でFirefox Helloのコンセプトを変更した。現在のように「特定のWebページを互いに見ながら動画で通話する」ことを前面に出すようになったのだ。同時に、システムアドオンと呼ばれる特殊な拡張機能として提供されるようになり、アップデートの頻度が本体に縛られなくなった。最近では、マルチプロセス機能（e10s）にも対応し、新ブランチも設けられていたので、開発が停滞していたとはいえない。

突然Firefox Helloが削除されることになった理由は、Bugzilla＠Mozillaの該当バグを見てもわからず、推測するほかない。昨年からMozillaは、「Great or Dead（成功か死か）」を合い言葉に利用者の少ないプロジェクトを打ち切っており、今回もその一環と考えられる。前記gHacksの記事が指摘するように、同じシステムアドオンであるFlyWeb（クラウドを介さずにスマートフォンと電子機器が相互に接続できる仕組み）に人的リソースを回すつもりなのかもしれない。

削除されたFirefox Helloはどうなるのだろうか。既にある種の拡張機能の形式になっているので、少し手を入れてMozilla Add-ons（AMO）で公開ということも考えられるが、残念ながらその望みは薄い。なぜなら、ベースとなるOpenTokの利用が有償だからだ。Mozillaにとって終わりが見えている機能に対して支出を続けるのは難しい。仮にアドオンとしての存続があるとしても、時限的な措置となるだろう。

（16/08/08追記）
米国時間の8月3日、Firefox 49ベータ版のリリースノートにおいてFirefox Helloの廃止が発表された。これを受けて、Hello のサポートが Firefox 49 で終了します | Firefox ヘルプでは、Firefox Helloの代替サービスを紹介している。

Firefox 48から一部環境でマルチプロセス機能（e10s）が有効化 Firefox 53で完全実施へ（再追記あり）

Firefox マルチプロセス

アドオンをインストールした環境は対象外

Firefox 48リリース版では、ついにマルチプロセス機能（e10s）の有効化が開始される。ただし一部環境では、という留保つきだ。有効化された環境では、Webページを閲覧中にクラッシュやハングが発生しても本体が巻き添えにならないので、安定性が向上する。

対象にならない環境を挙げておくと、まずは近々サポート対象外となるOS X 10.6／10.7／10.8のほか、クラッシュ率上昇の問題を抱えるWindows XP（Bug 1275039）はまるまる除かれる。また、アドオンをインストールしている場合も対象外となり（Bug 1250744）、e10sが有効の状態でアドオンをインストールすると、Firefoxの再起動によりe10sが無効になる（Bug 1232274）。さらに、アクセシビリティツールが動作している場合（Bug 1198459、Bug 1260190、Bug 1277882）やRTL言語*1ロケールの場合（Bug 1234673、Bug 1243882）もe10sは有効にならない。*2

注意が必要なのは、Windows上でテキストやその他の項目を拡大する設定にしていることも、「アクセシビリティツールが動作している」とみなされる点だ。アドオンを入れていないのにe10sが有効にならないときは、ここで引っかかっている可能性がある。また、e10sが有効なときは以前紹介したAsync Pan/Zoom（APZ）機能も有効になる。Firefox本体がキビキビと動作する反面、Flashプラグインの利用時に問題が生じるかもしれない。

Firefox 48のリリース直後、e10sが有効化されるのは対象環境のリリース版ユーザーの1％に制限される（Bug 1284958）。これを数に直すと全Beta版ユーザーの数とほぼ等しくなることからこの割合が選ばれた。Beta版に関してはFirefox 44のころから継続的にe10sのテストが続けられており、Firefox 48 Betaではユーザーの半数について開発サイクルの全期間（6週間）にわたりe10sが有効化されている。つまり単純計算では、上記の1％はその2倍の数となるわけだ。Mozillaはここで様子を見て、問題がなければ対象ユーザーの範囲を広げていく。非対象環境を除くと、全リリース版ユーザーの約41％にe10sが提供される見込みだという。

7年をかけた一大プロジェクト

e10sの開発には紆余曲折があった。当ブログの記事を振り返ってみると、Firefox.nextでコンテンツとクロームのプロセスを分離 - Mozilla Fluxが初出のようだ。2009年5月に開発計画が公表されており、今から7年も前のことになる。単一であったFirefoxのプロセスを、ユーザーインターフェイス担当の親プロセス（chromeプロセス）とコンテンツ（タブ）担当の子プロセス（contentプロセス）に分けるこのプロジェクトは、水を水素と酸素に電気分解することになぞらえてElectrolysisと呼ばれるようになった。e10sは冒頭のEと末尾のsの間に10文字が挟まっていることを踏まえた略称だ。

Firefoxのマルチプロセス化はフェーズ2へ - Mozilla Fluxでは、安定性の向上、マルチコアプロセッサを活用したパフォーマンスアップおよびセキュリティの強化がe10sのメリットであること、ただしセキュリティの強化につながるサンドボックス化は将来の課題であることに言及していた。2009年6月の段階で、既にe10sの基本線は引かれていたことがうかがえる。その後、プラグインの別プロセス化を達成した時点でFirefox 4の完成を優先することになったものの、2011年3月にFirefox 4がリリースされ、同年7月時点で開発が本格化していた。

ところが、Electrolysis（e10s）は終わるのか？ - Mozilla Fluxで紹介したように、2011年11月になってe10sプロジェクトは突然活動が停止されてしまう。開発の成果を得るには時間がかかりすぎるので、まずはより小規模な案件に集中して取り組むというのがその理由だ。このとき、プロジェクトは停止と言いつつ実質的に中止されたのではないか、との意見も多かったように記憶している。

しかし、e10sプロジェクトは再開された。Mozilla may bring the multi-process architecture Electrolysis (e10s) back from the dead - gHacks Tech Newsという記事が出たのが2013年4月のこと。記事から間を置かずに開発者が再開を宣言した。同年12月には、Firefoxのコードレビューの際、e10s互換性のチェックが必須化され、再度のプロジェクト停止はほぼあり得ない状況となった。

開発再開からも既に3年の月日が流れた。それだけFirefoxに大改造を施すのがたいへんだったわけだが、ようやくゴールが見えてきた。

完全実施はFirefox 53の予定

最新のロードマップによれば、Firefox 50（2016年11月8日〔米国時間〕リリース予定）の時点で、アクセシビリティツールが動作している場合やRTL言語ロケールの場合、それにタッチスクリーン環境においてe10sが有効化される。他方、Windows XPのサポート時期は明らかにされていない。FirefoxとしてXPのサポートをどこまで続けるかという議論がなされている状況からすると、e10sは無効のままということもあり得る。

また、Firefox 51（2017年1月24日リリース予定）以降、順次アドオンがインストールされた環境でもe10sが有効化されていき、Firefox 53（2017年4月下旬リリース予定）で全面的に有効化される。Firefox 51の時点では、WebExtensionsベースの拡張機能に加え、ホワイトリストに掲載された従来型アドオン*3が対象となる。Firefox 52でリストの対象を広げ、Firefox 53でリストを廃止するという流れだ。早くもFirefox 49 Beta版ではホワイトリストのテストが始まり（Bug 1282120）、当初は9つのアドオンがリストに載る。

Mozilla Add-ons（AMO）に登録済みでユーザー数の多いアドオンに関しては、Are we e10s yet?でe10sへの対応状況を一覧できる。unknownの項目が多くて驚くかもしれないが、Firefox側に互換性を維持するためのライブラリ（e10s shims：Bug 1063156）が搭載されているので、現時点で動作するものも多い。

Firefox 53でe10sが初期設定において有効化されるようになったら、その先に待っているのはcontentプロセスの複数化だ。該当プロジェクトはe10s-multiと呼ばれ、その計画によれば、まずはcontentプロセスを2つにする。このとき、Service Workerには独立したプロセスが与えられるようになるらしい。当面の目標はcontentプロセスを5つに増やすことだが、単純にプロセスを増やすとメモリ消費量も増えてしまうため、メモリの利用状況の最適化を図り、様子を見ながらプロセスを増やしていくことになる。

強制有効化の設定

最後に、e10sを強制的に有効化する方法を紹介しておこう。既にLatest topics > Firefoxのマルチプロセス機能を強制的に有効化する方法まとめ - outsider reflexにまとめられているが、about:configの画面でbrowser.tabs.remote.force-enableをtrueに設定することで、「アクセシビリティツールが動作している」か否かのチェックを回避できる。また、extensions.e10sBlocksEnablingとextensions.e10sBlockedByAddonsを両方falseに設定することで、「アドオンがインストールされている」か否かのチェックを回避できる。原則として開発者向けだが、e10sの安定性やAPZのパフォーマンスを重視するユーザーにとっても選択肢となるだろう。

（16/07/31追記）
E10s/Status/July22 - MozillaWikiによれば、e10sが対象環境のリリース版ユーザーの5％に展開されるのが8月15日、100％に展開されるのが8月22日となる見込みだ。また、本記事執筆後、アクセシビリティツールが動作している場合のe10s有効化はFirefox 51へと延期された。

なお、本文を若干修正した。

（16/08/06追記）
前回追記後に出たWhat’s Next for Multi-process Firefox | Future Releases（和訳）が、e10sに関し3つの新情報を提供している。

1点目。e10sが有効化される環境に、WebExtensionsベースの拡張機能またはホワイトリスト掲載の従来型アドオンがインストールされていることを含める時期を、Firefox 50に前倒しする。その前提として、Firefox 49リリース版でも少数の従来型アドオンは実験的にe10s有効化の対象となる。仮にBeta版のとおりであれば、その従来型アドオンは、Greasemonkey、Download YouTube Videos as MP4、Video Download Helper、Lightbeam、Flashblock、Adblock Plus、uBlock Origin、Emoji Cheatsheet、Awesome Screenshot Plusの9つになるはずだ（Bug 1247497参照。ただし古いバージョンは除く）。他方、ホワイトリストの撤廃時期（＝e10sの完全実施時期）については上記記事中で触れられていない。

2点目。本文で触れたe10s-multiを2017年前半のうちに実現する。これがcontentプロセスを幾つにすることを指すのかまでは明らかにされていない。そして、e10s-multiと並行してプロセスのサンドボックス化も導入する。ここでは、Mozillaがサンドボックス化にChromiumのコードを利用していることが重要になってくる。GoogleがChrome 50でWindows XP／Vistaのサポートを打ち切ったため、Mozillaは現状のサポート環境を維持しようとすれば、Chrome 49相当のコードしか使うことができない（Bug 1287426）。Windows Vistaの延長サポートが2017年4月11日に終了することも考慮に入れると、サンドボックス化の話はFirefoxがESR以外でXP／Vistaのサポートを打ち切る布石かもしれない。

3点目。e10s-multiおよびプロセスのサンドボックス化が実現した後、拡張機能ごとにサンドボックス化されたプロセスを割り当てる。これはもともとAdd-on SDKベースの拡張機能に関して計画されていた内容である。しかし、今のMozillaはWebExtensionsを強く推す立場だ。元の計画を、コストをかけてXUL/XPCOMベースの拡張機能まで対象にするよう広げるとは思えない。つまり、独立プロセスでサンドボックス化されるのは、WebExtensionsベースの拡張機能に限定されるだろう。

以上のほか、E10s/Status/Aug05 - MozillaWikiによれば、2016年8月15日時点で、e10sは対象環境のリリース版ユーザーの10％に展開されることになった。前回追記時よりも前倒しされており、Firefox 48でのe10s展開は順調なようだ。

なお、再び本文を若干修正し、注を1つ加えた。

（17/04/30追記）
本記事の情報は、既に古くなってしまっている。最新の動向はマルチプロセス化の完全実施に先行してFirefox 54で多プロセス化を開始 - Mozilla Fluxを参照してほしい。

*1:RTLはRight-to-leftの略で、アラビア語やヘブライ語のように右から左に記述するのがRTL言語だ。

*2:このほか、タッチスクリーン環境も対象外のようだ。

*3:XUL/XPCOMベースのものとAdd-on SDKベースのものを含む。

FirebugはFirefox 49本体に統合 現行の2.0.x系列はマルチプロセス機能（e10s）に対応せず

Firefox 開発ツール

Firebugは2006年から開発が続けられているWeb開発者向けツールで、「あなたはあらゆるWebページのCSS、HTML、及びJavaScriptをリアルタイムに編集、デバッグ、またはモニタすることが出来ます。」というのがうたい文句だ。Firefoxの拡張機能の中で最も有名なものの1つであり、現在でも200万人を超すユーザーがいる。開発チームのリーダーであるJan Odvarko氏はMozilla Corporationに在籍しているし、かつてはFirebugの動作に支障が出ることが、Firefox正式版のリリースを止めるバグ（Blockerバグ）にカウントされていたこともある。別格のアドオンといえるだろう。

そのFirebugが、Firefox 49で本体に統合される。公式ブログの記事"Unifying Firebug & Firefox DevTools"で説明されているとおり、FirebugはFirefoxの開発ツールに統合され、そのルック＆フィールは開発ツールのテーマとして維持されることになる（Bug 1244054）。Pixel Perfect*1やFireQuery、WebSocket MonitorといったFirebugの拡張機能も統合版Firebugと協調して動作する。

f:id:Rockridge:20160626212728p:plain

他方、現行のFirebug 2.0.x系列は、Firefoxのマルチプロセス機能（e10s）に対応しない。といっても、すぐに使えなくなるわけではない。たとえばFirefox 48の時点では、拡張機能が1つでもインストールされているとe10sが有効化されない仕様となっている。Mozillaもe10sが拡張機能に与える影響の大きさは十分承知しており、しばらくは上記の仕様が維持されるだろう。それとは別にe10sの有効・無効を切り替える設定もあるので、無効化してFirebug 2.0.x系列を使い続けることも可能だ。今のうちにFirefox Developer Editionで統合版Firebugを少しずつ試しておき、2.0.x系列からの乗り換え時期を探る手もある。

振り返ってみると、Firebug 3が2.0.x系列とは大きく違った形になることは、早くも2014年11月の時点でアナウンスされていた。"Firebug 3 – next generation of Firebug"はFirebug 3 alphaがリリースされたときの公式ブログの記事だが、そこではFirefoxの開発ツールが充実していく中、Firebugの重複する部分を整理し、Firefox本体との緊密な統合を実現することによって、ユーザー体験とともにパフォーマンスや安定性を向上させるという方針が示されていた。また、Firebug 3 beta 1がリリースされた2015年10月には、"Firebug & DevTools Integration ★ Mozilla Hacks – the Web developer blog"という記事が出て、Firebug 3はFirefox本体の開発ツール上に築かれた薄いレイヤーとなり、Firebugの独自機能も次第に開発ツールに移植されていくと説明されていた。

Firebug 2.0.x系列がe10sに対応しないことも、2014年12月の時点でアナウンスされている。"Firebug 3 & Multiprocess Firefox (e10s) ★ Mozilla Hacks – the Web developer blog"で述べられている内容は、要するに、e10sが有効化されるとFirebugはchromeプロセス側に置かれる一方で、操作の対象となるWebページはcontentプロセス側に置かれるので、処理の全面的な書き換えが必要になるということだ。本体の開発ツールと競合するのが目に見えているのに、膨大なコストをかけて書き換えを行う理由はない。そこで開発ツールと統合されたFirebug 3が作られることになった。

ただ、微妙な方針の変化もあったようだ。2015年12月にFirebug 3 beta 3がリリースされたのを最後に、拡張機能としてのFirebugは提供されなくなり、2016年2月には"Merging Firebug into the built-in Firefox Developer Tools"という公式ブログの記事で、Firebug 3のすべての機能をFirefoxにビルトインされたツールにする旨が発表された。当初は拡張機能としてのFirebugを残す方針だったが、どこかの時点で完全統合の方針に切り替わったのだろう。上記の記事によれば、Firefox本体の開発ツールに欠けた決定的な機能を提供する場合にのみ、Mozilla Add-ons（AMO）でFirebug 3を公開するという。

Firebug 3の統合はFirefox 49で完了するが、現行版のあらゆる機能が本体の開発ツールに実装されたわけではない。Bugzilla＠Mozillaには「Firebug Gaps」というバグが立てられており（Bug 991806）、今後もFirebug 2.0.x系列の機能の移植は続く。それでも、Firebugがその役割を終えたことは、Firefoxの開発ツールが1つのマイルストーンに達したことを意味する。WebExtensionsの普及という観点からも、Firebugが障害にならないのは大きいだろう。

*1:"Pixel Perfect 2: extension for Firefox Developer Tools ★ Mozilla Hacks – the Web developer blog"参照