Firefox 52以降はFlash以外のプラグインが使用不可に こっそり使い続ける方法とは

MozillaはFirefox 52でプラグインのサポートを大幅に縮小する。具体的には、自動的にインストールされるもの（OpenH264 Video CodecやWidevine Content Decryption Module）を除くと、サポートされるのはAdobe Flashプラグインだけとなり、他のプラグインは使用できなくなる（Bug 1269807）。*1

アドオンマネージャの〔プラグイン〕の項目を見ると、あっさりした表示になっているのが分かる。Firefox 51までは有効・無効にかかわらず列挙されていたプラグインが、きれいさっぱり無くなっている。

Firefox 52以降もFlash以外のプラグインを使い続けたければ、延長サポート版（ESR）を利用してください、というのがMozillaのスタンスだ。この場合、Firefox 53以降に本体に追加される新機能は利用できなくなるため、ユーザーは（Flash以外の）プラグインを取るか新機能を取るかの二者択一を迫られることになる。

Flash以外のプラグインをこっそりと使い続ける方法を以下に紹介しよう。もっとも、今後のFirefoxはこれらのプラグインが動いていないことを前提に開発が進むため、Flash以外のプラグインがクラッシュの原因になっても修正されることはない点に注意してほしい。

上で述べたように、FirefoxのESRではFlash以外のプラグインもサポートが続いているわけだが、それを実現するのがplugin.load_flash_onlyの設定だ。about:configの画面で設定の欄を右クリックし、「新規作成」から真偽値の項目を選ぶ。そして、plugin.load_flash_onlyをfalseに設定する。

これで本体を再起動すればプラグインが無事復活……とはいかない。プラグイン用のキャッシュファイルが書き換えられており（Bug 1307501）、設定を変えても復活しないからだ。本体を再起動する前にこのキャッシュファイルを削除し、改めて作成するよう促す必要がある。

pluginreg.datという名のキャッシュファイルは、プロファイルフォルダ内に存在する。プロファイルフォルダへの移動は、Firefoxのヘルプメニューからトラブルシューティング情報（about:support）のページを呼び出し、〔アプリケーション基本情報〕のプロファイルフォルダ欄から「フォルダを開く」のが手っ取り早い。

まとめると、plugin.load_flash_onlyの設定をfalseの値にした状態で追加し、プロファイルフォルダ内のpluginreg.datというファイルを削除してから、Firefox本体を再起動する。これでFlash以外のプラグインは復活する。

（17/01/23追記）
同一プロファイルでESRと非ESRを切り替えた場合に混乱が生じないようにするため、plugin.load_flash_onlyの設定を追加して値をfalseにし、再起動するだけで、Flash以外のプラグインが復活するようになった（Bug 1330998）。もっとも、将来的に設定による切り替えはできなくしていく方針が示されており（Comment 17参照）、本記事の方法がいつまで通用するかはわからない。

なお、注に書いたAdobe Primetime CDMは、Firefox 52でアドオンマネージャに表示されなくなり（Bug 1329538）、Firefox 53でサポートが廃止される（Bug 1329543）。

*1:ちなみに、このバージョンから、Adobe提供のPrimetime Content Decryption Moduleはオンデマンドでのインストールとなる（Bug 1304899）。

Firefox 52からWindows XPはESRでのサポートへ移行 Vistaもやや遅れて追随か（追記あり）

Firefoxが通常版でWindows XPをサポートするのはバージョン51までであることが明らかになった。バージョン52以降は法人向け延長サポート版（ESR）でのみサポートされる（Bug 1303827）。

もともとこの話はFirefox 46のリリース前からあって、XP上のFirefoxユーザーの数に配慮した結果、先送りになっていた。Mozilla Corp.の従業員からも、サポートを変更するタイミングとしてはFirefox ESR 52のリリース時という観測が出ていたので、意外感は全くない。

Firefox 52のリリース（2017年3月7日予定）と同時なのか、それとも多少遅れるのかは定かでないものの、XP上のFirefox 51ユーザーに対してはESR 52の自動アップデートが提供されることになりそうだ。2016年3月時点で既に、そうした措置は技術的に十分可能だとされており、そこに1年分のリリースエンジニアリングの進歩が加われば、ますます簡単だろう。

Firefoxは変則的なリリース間隔を採用しているが、これは要するにESRのベースとなるバージョンのリリース時期を毎年同じくらいの時期にするものなので、ESRのサポート終了時期の予測は立てやすい。ESR 45.8のサポートが2017年6月12日まで続くことからすると、ESR 52.8のサポートが終了するのは、2018年6月のどこかになるはずだ。Microsoftのサポートが2014年4月8日に終了していることを考えると、かなり手厚い措置といえるのではないか。

XPのサポートがESRに移行すると決まったことで、俄然注目されるのはWindows Vistaの扱いである。こちらは2017年4月11日にMicrosoftのサポートが切れる。Firefox 52のリリース後だが、Firefox 53のリリース（2017年4月18日予定）よりは前なので、Vista上のFirefox 52ユーザーにESR 52.1を提供すれば、ダウングレードにはならない。

サポートするOSを減らせば、Mozillaとしては製品版リリースまでに行われる各種テストを絞り込めるだけでなく、外部から取り入れているオープンソースのコードが、FirefoxのサポートしているOSに合わないといった問題も避けられる。たとえば、プロセスのサンドボックス化にChromiumのコードを使おうとすると、GoogleがXP／Vistaのサポートを打ち切っているので古いバージョンしか選べないという状況は、FirefoxのサポートOSをChrome（Chromium）と同じにしてしまえば解決するわけだ。

しかも、最近Mozillaは64bit版Firefoxの本格提供に向けて動き出したが、64bit版はWindows 7以降しかサポートしていないため、64bit版が主流になると32bit版だけVistaのサポートを追加する格好になる。また、Firefoxの基盤にあたるGeckoにServoという新開発のブラウザエンジンの技術を取り入れていく話についても、ServoがやはりWindows 7以降しかサポートしないので、Vistaのサポートを残し続けると移植の障害になりかねない。

そのうえ、VistaのマーケットシェアはXPよりもはるかに小さいので、ESRへの移行がFirefoxユーザー全体の中で与えるインパクトも限定的だ。Vista上のユーザーにとっても、Chromeがさっさと撤収する中、MicrosoftのOSサポートが切れてから1年以上もブラウザのサポートを受けられるのは、決して悪い話ではない。

こうして見てくると、MozillaがWindows XPに引き続きVistaも同様の扱いとする可能性は非常に高いといえるだろう。

（16/09/29追記）
やはりVistaもESRでのサポートに移行する模様である。米国時間の2016年9月26日に登録されたBug 1305453では、「XP／Vista上のユーザーをESR 52に移行させる」と表現されている。XPとVistaを区別しない書きぶりは、Vista上のFirefox 51ユーザーに対しても、Firefox ESR 52の自動アップデートが提供されるという趣旨にも読める。なお、Firefox Nightly 53の開発サイクル冒頭でインストーラに手が加えられ、XP／Vista上にはインストールできなくなるという。

ESRチャンネルに移行した場合、本当に2018年6月までサポートが続くのか疑問に思う向きがあるかもしれない。だが、ユーザー数が少ないOS X 10.6～10.8でさえ、Firefox 48を最後に通常のチャンネルではサポートが打ち切られた後も、ESRチャンネルでは52.2（サポート終了日：2017年8月7日）までサポートが継続されることになっている（Bug 1293777）。それよりもはるかにユーザー数が多いXP／Vistaについて、ESRのサポート期間の途中でOSのサポートが打ち切られる可能性はまずないと考えてよいだろう。

（16/10/25追記）
Mozillaの技術者から、XPおよびVistaユーザーは自動的にESR 52チャンネルに切り替わるというコメントが出た。本文に記載したとおり自動アップデートが提供されることになる。

（16/11/27追記）
当初の話からは若干変わって、ESRへの切り替えはFirefox 53のリリース時点で行われるようだ（Bug 1315083）。とはいえ、もともと通常版Firefox 52とESR 52.0は、若干の設定の違いを除けば同じものなので、この計画変更がユーザーに与える影響はごく小さい。なお、この時点で通常版のサポートは、Windows XP／Vistaだけでなく、サーバ向けのWindows 2003／2008（R2を除く）でも終了する（Bug 1317780）。

関連記事

• Firefox 48から一部環境でマルチプロセス機能（e10s）が有効化 Firefox 53で完全実施へ（追記あり） - Mozilla Flux〔16/08/06追記部分〕
• OS X 10.6／10.7／10.8のサポートはFirefox 47まで Windows XPのサポートは当面継続（追記あり） - Mozilla Flux

Windows向けFirefox 52で64bit版が主役に 2017年後半には自動アップデートも提供へ（追記あり）

Windows向け64bit版Firefoxは、2014年11月に発表されたプランからすると提供がかなり遅れており、Mozillaとしても慎重ならざるを得なかったのか、これまで新たな計画が明らかにされることはなかった。だが、ここにきてFirefox/Win64 - MozillaWikiに具体的なスケジュールが掲載されるようになり、本腰を入れてきた感がある。

上記のスケジュールは、１つひとつが簡潔な記載になっているため、読み解くには様々な情報と突き合わせる必要がある。現在判明しているところでは、まず、2016年9月下旬から10月上旬にかけて、新しいダウンロードページのテストが実施される。Firefox 50のリリース予定日が11月8日（米国時間。以下同じ）であることを踏まえたものとみられ、おそらくそのリリースに合わせて、MozillaのWebサイトのトップページから64bit版Firefoxのスタンドアローン型インストーラ（フルインストーラ）への導線が強化される。

次のステップはFirefox 52で、適格性のあるユーザーに対しては、軽量インストーラ（スタブインストーラ）が初期設定で64bit版をインストールするようになる（Bug 797208）。ここで、適格性のあるユーザーとは、搭載メモリが4GB以上のPCでWindows 7以降のOSを使用しているユーザーを指す*1。軽量インストーラはMozillaのWebサイト以外でも広く公開されており、多くのユーザーがこの時点で64bit版に触れる機会を持つことになるはずだ。脇役だった64bit版は、ついに32bit版を押しのけて主役となるわけだ。ちなみに、かつてのプランでは、軽量インストーラに64bit版が統合され、ユーザーが選択できるようになるのがフェーズ2とされていた。今回のスケジュールは、64bit版を初期設定にした点が目新しい。

最後に、2017年後半には、適格性のあるユーザーが32bit版を使用している場合、64bit版が自動アップデートで提供される（Bug 1274659）。かつてのプランでフェーズ3と呼ばれていた段階であり、ここまできてようやく、2014年11月に発表されたプランが完遂されたことになる。Firefoxのリリーススケジュールを見ると、2017年の後半にリリースされるのは3バージョン。すなわち、8月8日リリースのFirefox 55、10月3日リリースのFirefox 56、11月28日リリースのFirefox 57だ。MozillaWikiの改版履歴をチェックするとわかるが、当初は2017年第2・第3四半期となっていたものが、単に第3四半期とせず、後半に変更されている。つまり第4四半期にずれ込むことを考慮したわけで、Firefox 56が暫定的なターゲットではないか。*2

スケジュール通り進められるかどうかは、前提条件を確保できるか否かにかかっている。MozillaはFirefox 52でFlash以外のNPAPIプラグインのサポートを廃止することにしているが、この予定が延びてしまうと、64bit版を主役にするという計画にも狂いが生じる。また、FlashプラグインについてMozillaは自前でサンドボックス化を実現していくが、これに関連するバグを潰しきれるかという問題がある。さらにいえば、バイナリベースの拡張機能に関し、XPCOMによるものは既にFirefox 41で廃止されたが、js-ctypesによるものの廃止にあたっては、WebExtensionsによる代替機能の提供を考慮する必要があるかもしれない。

64bit版への移行は、ポインタサイズが倍になる関係で消費メモリが25％増しになるというデメリットもあるが、処理の高速化に加えて、アドレス空間消尽の問題がなく、アドレス空間配置のランダム化（ASLR）が強化されてセキュリティが向上するなど、メリットも大きい。今回のスケジュールのまま開発が進むことを期待したい。

（17/02/12追記）
本記事執筆後に動きがあり、本文の内容は最新ではない。2017年10月上旬までにWindows向け64bit版Firefoxの自動アップデートが開始 - Mozilla Fluxを参照してほしい。

関連記事

• Windows向け64bit版Firefox 43が正式公開 一部のベンチマークでは32bit版を上回る結果も - Mozilla Flux
• Windows向け64bit版Firefox 42がひっそりと公開 NPAPIプラグインのサポートは極めて限定的 - Mozilla Flux
• Windows向け64bit版の正式公開はFirefox 40から（再追記あり） - Mozilla Flux
• Firefox 38でWindows向け64bit版はフェーズ1が完了 軽量インストーラへの統合が今後の課題 - Mozilla Flux
• 64bit版Firefoxへの道のり（追記あり） - Mozilla Flux

*1:Windows向け64bit版FirefoxはWindows 7以降でしか動作しない。

*2:ちなみに、OS X向けFirefox 53では、Windows向けに先んじてビルドがIntel 64bit版に一本化される見込み（Bug 1295375）。

Firefoxは2017年も変則的なリリース間隔を採用

2016年に入ってから、Firefoxのメジャーアップデートのリリース間隔は6週間に固定されなくなったが、この方針は2017年も継続される。RapidRelease/Calendar - MozillaWikiに記載されているとおり、6週間から8週間の変則的なスケジュールが採用され、年に7回のメジャーアップデートが行われる。

以下がその内容だ（米国時間ベース）。なお、2017年のクリスマス付近にリリース予定日が重ならないため、50.0.1（修正後50.1.0）のような特殊なスケジュールは組まれていない。

リリース予定日	正式版	ESR
2016-11-15	Firefox 50	Firefox 45.5
2016-12-13	Firefox 50.1.0	Firefox 45.6
2017-01-24	Firefox 51	Firefox 45.7
2017-03-07	Firefox 52	Firefox 45.8; 52.0
2017-04-19	Firefox 53	Firefox 45.9; 52.1
2017-06-13	Firefox 54	Firefox 52.2
2017-08-08	Firefox 55	Firefox 52.3
2017-09-26	Firefox 56	Firefox 52.4
2017-11-14	Firefox 57	Firefox 52.5
2018-01-16	Firefox 58	Firefox 52.6

変則的なスケジュールの場合、過去のように年8回のメジャーアップデートを行うことができなくなる一方、Update on 2016 Firefox Release Schedule | Future Releasesで指摘されているように、OSの大型アップデートなどのイベントに合わせてリリースのタイミングを柔軟に調整できる。また、今回、Firefox 49のリリースはバグ潰しのために1週間遅れたわけだが、こうしたことがあってもFirefox 50のリリース予定日を維持できるのは、スケジュールに余裕をもたせてあるからだ。

ESR（延長サポート版）についても、正式版のリリースサイクルが延びることは延長サポート期間が延びることを意味する。安定した環境を求めるユーザーにとって、サイクルが6週間固定でないことの恩恵は大きいといえるだろう。

2年続けて同様のスケジュールを採用し、しかも早々とこの時期（正確には2016年8月末）に2017年の予定を打ち出しているところをみると、Mozillaは今後もこのリリース間隔を維持していくと思われる。

（16/10/29追記）
RapidRelease/Calendarの修正に合わせて記載を更新した。

（16/11/15追記）
RapidRelease/Calendarの修正に合わせて記載を更新した。

（17/02/13追記）
RapidRelease/Calendarの修正に合わせて記載を更新した。

（17/04/20追記）
RapidRelease/Calendarの修正に合わせて記載を更新した。

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

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の動作の高速性を選びたいマニア向けに紹介しておく。

*1:SQLiteのジャーナルモード - なべ’s blog参照