読者です 読者をやめる 読者になる 読者になる

Mozilla Flux

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

Placesデータベースの読み書き処理を大きく減らす裏技(Firefox 49以降)

Fx解説

Firefoxはブラウジング履歴やブックマークなどの情報をPlacesと呼ばれるSQLiteデータベースに記録している。Placesが壊れてしまうとブックマークが失われたり、ロケーションバーからうまく候補を呼び出せなくなったりするため、FirefoxはジャーナルモードというSQLiteの機能を利用して、データベースの保護に努めている。

Placesを保護する手段の1つが、ログ先行書き込み(WAL:Write-Ahead Logging)だ。SQLiteでは、トランザクション開始から終了までの更新内容を順次「-shm」ファイルに書き込み、コミット時に「-wal」ファイルへと更新内容を書き込む*1。コミットした時点では本体データベースファイルに更新内容を書き込まないため、クラッシュしても本体は無傷で残り、トランザクションも迅速に完了できるというわけだ。Placesの場合、このWALジャーナリングモードが初期設定で有効化されており、本体であるplaces.sqliteのほかに、places.sqlite-shmとplaces.sqlite-walという2つのログファイルが作成される。

これとは別に、PlacesではFULL同期モードが初期設定で採用されており、コンテンツが安全にデータベースに書き込まれたのを確認してから次の処理に進むようになっている。SQLiteの公式サイトの説明によれば、WALジャーナリングモードは通常NORMAL同期モードと呼ばれる相対的に軽い処理のモードを採用することが一般的らしい。あえて重いモードを選択しているあたり、Placesを厳重に保護しようとするMozillaの判断がうかがえる。

だが、これらの保護措置はFirefoxのテスト自動化にとって妨げとなる。大量のディスク入出力(I/O)が発生するからだ。そこで、Firefox 49ではWALジャーナリングモードとFULL同期モードを両方オフにする隠し設定が導入された(Bug 1272025)。これにより、Firefoxの自動テストのような負荷の高い環境では、ギガバイト単位でディスクI/Oを節約できるという。

危険度の高い変更であるため、隠し設定は通常よりも複雑なものとなっている。まず、about:configの画面でplaces.database.disableDurabilityの設定を新規作成し、真偽値をtrueにする。次に、環境変数を追加する。設定値は何でもよく、変数の存在だけが重要だ。ALLOW_PLACES_DATABASE_TO_LOSE_DATA_AND_BECOME_CORRUPTがそれだ。Windowsだとコントロールパネルの「システムの詳細設定」からユーザー環境変数を追加できる。トラブルシューティング情報(about:support)からプロファイルフォルダを開き、places.sqlite-shmとplaces.sqlite-walのファイルが消えていることを確認できれば成功だ。

隠し設定が有効化されると、WALジャーナリングモードはMEMORYジャーナリングモードへと変更され、ロールバックジャーナルと呼ばれるデータベースのバックアップがメモリ上に作成されるようになる。書き込みは直接Placesデータベースに対し行われるので、ログの読み書き分のディスクI/Oがなくなるわけだ。しかも、Placesへの書き込み完了を待たずに次の処理へ移るため、ユーザー側からは書き込み処理に要する時間も短縮されたように見える。

一般ユーザーが使用することを想定していない裏技ではあるが、履歴やブックマークの完全性よりもFirefoxの動作の高速性を選びたいマニア向けに紹介しておく。

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

Fx情報

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-flexflexに変換
  3. -webkit-inline-box-moz-inline-boxに変換
  4. -webkit-inline-flex-moz-inline-flexに変換

その他

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

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

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

Fx情報

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が削除

Fx新着

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で完全実施へ(追記あり)

Fx情報

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

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

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

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

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

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

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

Fx情報

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*1FireQueryWebSocket 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が障害にならないのは大きいだろう。

Firefox 49本体のみで履歴等データベースのVACUUMが可能に

Fx情報

FirefoxはSQLiteというデータベース管理システムを用いて履歴とブックマークを管理しており、このデータベースのことをPlacesと呼ぶ。具体的にはplaces.sqliteというファイルだ。places.sqliteの肥大化と断片化はFirefoxのパフォーマンスを低下させるおそれがあるため、Firefox 3.6以降、データベースの断片化割合を推測しながら30日から60日に1回、アイドル時にVACUUM処理が行われる仕様となっている(Bug 512854)。places.sqlite内の項目が削除されて生じた空きレコードは、VACUUM処理によって解消され、それによって初めてファイルが圧縮されることになる。

ここまでは前提のおさらいだが、そうした知識があるかは別にして、要するにVACUUMすればFirefox本体の動作が軽くなると考えて、手動でこれを行うべく拡張機能を導入するユーザーが一定数存在する。実際には頻繁にVACUUM処理を実行してもあまり意味はないのだが、それはさておき拡張機能を入れるとなると互換性の問題が生じる。つまりFirefoxをバージョンアップすると動かなくなるケースが出てくるわけだ。

しかし、Firefox 49でトラブルシューティング情報(about:support)のページに「Places Database」(Placesデータベース)の欄が加わり、"Verify Integrity"(整合性の検証)というボタンが付いたことで、状況が変わるかもしれない(Bug 522668)。about:supportはロケーションバーに直接打ち込むか、メニューパネルのヘルプメニューから「トラブルシューティング情報」を選択すると呼び出せるが、そこにある整合性の検証ボタンをクリックすると処理が始まる。しばらく待つと結果が表示され、その中でVACUUM処理がされたことがわかる。処理前後のデータベースサイズを示してくれるので親切だ。

f:id:Rockridge:20160614000628p:plain

新規プロファイルで試してみた結果を以下に示しておこう。VACUUMの項目を見るとデータベースサイズは変わっていないが、削除された履歴やブックマークがない状態なのでこうなるのは当然である。

> Integrity check
+ The database is sane
> Coherence check
+ The database is coherent
> Orphans expiration
+ Database cleaned up
> Vacuum
Initial database size is 10240 KiB
+ The database has been vacuumed
Final database size is 10240 KiB
> Statistics
Database size is 10240 KiB
user_version is 32
page_size is 32768
cache_size is -2048
journal_mode is wal
synchronous is 1
History can store a maximum of 104858 unique pages
Table moz_places has 11 records
Table moz_historyvisits has 4 records
Table moz_inputhistory has 0 records
Table moz_hosts has 4 records
Table moz_bookmarks has 15 records
Table moz_keywords has 0 records
Table sqlite_sequence has 0 records
Table moz_favicons has 8 records
Table moz_anno_attributes has 3 records
Table moz_annos has 1 records
Table moz_items_annos has 4 records
Table sqlite_stat1 has 14 records
Index sqlite_autoindex_moz_inputhistory_1
Index sqlite_autoindex_moz_hosts_1
Index sqlite_autoindex_moz_keywords_1
Index sqlite_autoindex_moz_favicons_1
Index sqlite_autoindex_moz_anno_attributes_1
Index moz_places_faviconindex
Index moz_places_hostindex
Index moz_places_visitcount
Index moz_places_frecencyindex
Index moz_places_lastvisitdateindex
Index moz_historyvisits_placedateindex
Index moz_historyvisits_fromindex
Index moz_historyvisits_dateindex
Index moz_bookmarks_itemindex
Index moz_bookmarks_parentindex
Index moz_bookmarks_itemlastmodifiedindex
Index moz_places_url_uniqueindex
Index moz_places_guid_uniqueindex
Index moz_bookmarks_guid_uniqueindex
Index moz_keywords_placepostdata_uniqueindex
Index moz_annos_placeattributeindex
Index moz_items_annos_itemattributeindex

もはやPlacesをVACUUMするためにわざわざ拡張機能を入れる理由はなくなった。拡張機能を入れなければ、互換性問題に悩まされることもない。ただし、より高度なメンテナンスを行う場合は、Places Maintenanceのような拡張機能にもまだ出番がある。