Firefox本体のアップデートに関して、現行のFirefox 62には3つの設定がある。オプション画面の〔一般〕セクションをスクロールしていくと見つかるが、1)更新を自動的にインストールする、2)更新の確認は行うが、インストールするかを選択する、3)更新の確認は行わない、となっている。初期設定は1)だが、3)への変更も容易なのが現状だ。Firefox 63ではこの3)の設定を削除し、1)と2)だけとする（Bug 1420514）。app.update.enabledの設定そのものが削除されたため、about:configから復活させることもできない。 Mozillaの狙いは、ユーザーにできるだけ最新バージョンのFirefoxを使ってもらうことにある。Firefox Public Data ReportのUser Activityによれば、リリース直後を除くと、デスクトップ版Firefox

2018年12月11日（米国時間）リリース予定のFirefox 64では、RSS/Atomフィードの購読機能とライブブックマーク機能が本体から削除される（Bug 1477667）。その理由は"Removing feed support from Firefox"に詳しいが、要約すると、Firefoxユーザーの99.9％が使用しない機能でフィード自体も廃れつつあるので、デスクトップ版専用の古いコードをメンテナンスしていくコストが釣り合わなくなったというものだ。当初はFirefox 63で削除する話も出ていたが、作業量とタイミングの兼ね合いで見送られた。 ライブブックマーク機能の削除に伴い、既存のライブブックマークは自動的にOPMLファイルに変換して保存され、個別の記事はそのURLのブックマークへと置き換えられる（Bug 1477672）。Firefoxが生成したOPMLファイルを別のフィード

2017年10月18日にはてなブックマークFirefox拡張がバージョン3.0.0へとアップデートされ（最新バージョンは3.0.2）、Firefox Quantum以降に対応するようになった。ところが、Windows版Firefox Quantumで日本語入力がおかしくなる問題が発生している。 具体的には、ツールバー上のアイコンをクリックすると表示される、コメントの入力領域にIMEで入力する際、候補ウィンドウが常に画面の左上隅に出現する（Bug 1419285）。IMEの種類には関係がなく、Microsoft IMEはもちろん、ATOKやGoogle日本語入力でも現象は共通だ。候補を確定してしまえば文字列が入力領域に現れるとはいえ、拡張機能の使い勝手が損なわれることおびただしい。 実は、この問題はWebExtensionsベースの拡張機能が表示するパネルであれば、どこでも起きうるもの。はて

新形式の長所と短所 Firefox Quantumでは旧式の拡張機能が一切使えないようになっており、サポートされるのはChromeの拡張機能と共通する部分の多い新形式（WebExtensions）のものだけだ。Firefox 56以前で使用していた拡張機能が既にこの新形式に移行している場合はいいが、そうでなければ同じような機能を提供する別の拡張機能を探す必要がある。 もっとも、新形式の拡張機能は従来よりも制約が大きい。旧式拡張機能の時代に、Firefox本体を大幅に書き換えることさえ許容していた結果、さまざまなバグの温床となったうえ、拡張機能の互換性を維持することが重荷にもなっていたことに対する反省を踏まえ、新形式では拡張機能ができることを絞ったのだ。特に、Firefox本体のユーザーインターフェイス（UI）にはごく限定された範囲でしか介入できないようになっている。そのため、従来のようなオ

Firefoxはブラウジング履歴やブックマークなどの情報をPlacesと呼ばれるSQLiteデータベースに記録している。Placesが壊れてしまうとブックマークが失われたり、ロケーションバーからうまく候補を呼び出せなくなったりするため、FirefoxはジャーナルモードというSQLiteの機能を利用して、データベースの保護に努めている。 Placesを保護する手段の1つが、ログ先行書き込み（WAL：Write-Ahead Logging）だ。SQLiteでは、トランザクション開始から終了までの更新内容を順次「-shm」ファイルに書き込み、コミット時に「-wal」ファイルへと更新内容を書き込む*1。コミットした時点では本体データベースファイルに更新内容を書き込まないため、クラッシュしても本体は無傷で残り、トランザクションも迅速に完了できるというわけだ。Placesの場合、このWALジャーナリン

アドオンをインストールした環境は対象外 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 126

Firefox 44がリリースされ、アップデート可能になっているが、アップデート後に再起動してみると、はてなブックマーク拡張（バージョン2.3.8.1-let-fixed）が全く動かなくなっている。過去記事・Firefox 44はアドオン互換性に要注意で懸念していた事態が現実化してしまった。近日中に公式修正版が提供されると信じているが、それまで同拡張が使えないのは不便極まりない。 有志による修正版を導入すれば、当面の問題をしのぐことができる。まずはabout:configの画面を開いて、xpinstall.signatures.requiredの設定をfalseに変更し、未署名の拡張機能を有効化しよう。次に、修正版が公開されているGitHubのページへ移動する。ここからの手順は、過去記事・はてなブックマーク拡張の使い勝手を取り戻す（追記あり）で紹介したとおりだ。 「ファイルからアドオンをイ

Firefox Developer Edition 41で、はてなブックマーク拡張が機能しなくなっている。FirefoxのビルドID：20150712004007と拡張機能のバージョン2.3.7.1-signedとの組み合わせで確認した。前回記事にしたときは、Firefox Nightly 36で動かず、Aurora 35だと大丈夫だったのだが、今回は、Nightly 42も含めて全く使えない状態だ。 実は、同アドオンが機能しなくなったのは、Nightly 41の途中から。つまり、このとき加えられた変更が、Developer Edition 41でも維持されているわけだ。不具合であれば現時点までに修正されている可能性が高く、仕様変更が原因とみられる。 Firefox JavaScript changelog - JavaScript | MDNを見てみよう。Firefox 41のJavaS

長い間、Firefoxでルビを表示させるためには、HTML Rubyのようなアドオンをインストールする必要があった。しかし、Firefox 38（米国時間の2015年5月12日にリリース予定）では、本体のみでルビ表示に対応する。 HTMLパーザ側には、すでにFirefox 33の時点で最新の仕様が実装されていた（Bug 664104、Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules）。CSS3 Rubyの実装も2014年9月ころから本格的に進められていたが、Firefox Nightly 38で設定が有効化されるに至った（Bug 1039006、Intent to ship: CSS Ruby）。won't fix: ルビ on Firefoxで紹介されていたころは

Adobe Flash Playerプラグインの保護モードは、悪意のあるFlashコンテンツ（SWFファイル）からの攻撃を制限するセキュリティ機能だが、Mozillaが最近Windows上でFirefox 35 Betaを利用するユーザーの一部を対象に実験を行ったところ、保護モードを有効にした場合、クラッシュやハングの率が無効の場合の2倍になることが判明した。 この結果を受けて、Windows版Firefox 36 Beta、37 Auroraおよび38 NightlyでFlashの保護モードを無効化する実験が開始されることになった（Bug 1119941）。結果次第では、リリース版で保護モードがデフォルトで無効となる可能性もある。セキュリティと利便性のバランスをどのようにとるかは常に難問であり、今回の実験後もMozillaは難しい決断を迫られることになりそうだ。 ところで、こうした実験が

Firefox本体がバックグラウンドで更新されると、OSの通知機能を通じて、ユーザーにアップデートの準備ができた旨が知らされる。見逃しにくいように通知は大きめに表示されるものの、少し時間が経つと消えてしまう。ヘルプメニューから「Firefoxについて」を選択すれば更新の有無を確認できるとはいえ、わかにくさは否めない。 一方、開発者向けに公開されたFirefox Developer Editionでは、アップデートの通知方法が改良されている（Bug 1080406）。準備が完了した時点でバーガーボタンに星印が付され、メニューパネルを開くと再起動を促すメッセージが下部に表示される。見逃しがないうえ、Australisにもマッチした優れたデザインだ。 実はこの通知機能、Auroraチャンネル限定のものではないため（Bug 1100079）、Firefox 35 Betaでも設定を変えればすぐに利

Windows版Firefoxをいったん終了させ、改めて起動した際、「Firefoxは起動していますが応答しません。新しいウィンドウを開くにはまず既存のFirefoxプロセスを終了させるか、コンピュータを再起動させなければなりません。」というメッセージを目にしたことはないだろうか。終了直前に、たくさんタブを開いていたり、Flashプラグインを利用したコンテンツ（動画など）を閲覧していたりすると、このメッセージを含む「Firefoxの終了」ダイアログを見る率が高いようだ。 単にシャットダウン処理が追いついていないだけであれば、少し間を置いてからFirefoxを起動し直せばよい。だが、Firefoxのプロセスがメモリ上に残ったまま、プロファイルがロックされてしまう場合がある。こうなると、上記メッセージのとおり、タスクマネージャーからFirefoxのタスクを終了させるか、PCを再起動させない限り

まもなくFirefox 33がリリースされるが、Windows版Firefox 33では、OMTC（Off Main Thread Compositing）と呼ばれる機能が有効化されている（Bug 1074045）。これは、描画の前段階としてWebページ内の各要素から成る複数のレイヤーを一つにまとめる処理を、メインスレッドから独立したcompositorスレッドで行うというものだ（参照1、参照2、参照3）。 OMTCが有効化されることで、Firefox本体の応答性が高まり、キビキビとした動作となることが期待される一方、これまでとは処理プロセスが変わるため、クラッシュやハングの原因となる可能性がある。この点についてMozillaは、Firefox 32でOMTCを有効化することを見合わせ、Beta版で判明したバグを潰していくことによって、目立ったクラッシュ率の増加などが起きないようにしている

Firefox 10の主な新機能といえば、アドオンの互換性確認の柔軟化やユーザーインターフェイスの改良、Web開発者向けツールの拡充などが中心で、処理の高速化はあまり意識されていない。Firefox 9の型推論（Type Inference）のように目立ったところがないからだろう。だが、ベンチマークを用いて性能を測ってみると、けっこう改善されていることがわかる。 実際の数字を見てみよう。比較対象は、以下のとおりWindows 7 SP1（64bit版）上で動作する32bit版のFirefox 9.0.1とFirefox 10.0。新規プロファイルを初期設定のまま利用し、アドオンはすべて無効化するが、プラグインはShockwave Flash 11.1（r102）だけを有効にした。使用したハードウエアは、CPUがIntel Core i5-2410M 2.30GHz、GPUがIntel HD

Firefox 9の目玉機能であるJavaScriptの型推論（Type Inference：TI）。この機能をリリース版に投入できたことによって、ようやく本当に高速リリースサイクルを維持するめどが立ったといっても過言ではない。それくらい、TIの実装は開発プロセスにおいて重要なチャレンジだった。 話は2011年8月上旬に遡る。同年6月にJavaScriptエンジンのモジュールオーナーを継いだMozillaのDavid Mandelin氏が、mozilla.dev.planningニュースグループに1本のスレッドを立てた。『Shipping Type Inference and Other "Irreversible" Changes』と題されたそのスレッドにおいて、Mandelin氏は、TIの導入に当たって開発プロセス上の課題があると指摘した。 TIはJavaScriptエンジン全体を通じ

Firefox 9の注目点は、何といってもJavaScriptの実行速度の向上だ。Mozilla Developer Streetで紹介されているように、型推論（Type Inference：TI）と呼ばれる技術が実装され、JaegerMonkey（JM）が従来よりも高速なコードを生成できるようになった。今後はこのJM＋TIがJITコンパイラの中核を担い、TraceMonkeyはその役割を終えることになる。 はたして型推論の効果は出ているのか。ベンチマークをとってみよう。比較対象は、以下のとおりWindows 7 SP1（64bit版）上で動作する32bit版のFirefox 8.0.1とFirefox 9.0（Beta 6）。新規プロファイルを初期設定のまま利用し、アドオンはすべて無効化するが、プラグインはShockwave Flash 11.1（r102）だけを有効にした。なお、初期設

（2011/12/21追記） Mozillaが公式ブログでGoogleとの提携契約の延長を発表した（『Mozilla and Google Sign New Agreement for Default Search in Firefox』）。秘密保持条項があるため契約の詳細は記載されていないが、Mozillaは今後3年間この提携関係が継続すると明言している。 （2011/12/07追記） CNET News『Don't write off Mozilla-Google revenue deal as dead（Mozilla・Googleの収入提携を死んだことにするな）』という記事が出た（CNET Japanによる抄訳）。Stephen Shankland記者がGoogleとMozillaに取材したところ、GoogleはMozillaとの契約関係がなお継続している事実を認め、Mozilla

（2012/01/28追記） Mozilla Add-ons Blogにて予定どおりFirefox 10からこの措置が実施されるとの発表があった（『Add-on Compatibility for Firefox 11』）。対象となるのはFirefox 4以降に対応した拡張機能で、バイナリコンポーネントを含むアドオンや、テーマ、辞書、言語パックは対象外となる。 Firefoxの高速リリースサイクルに対する一般ユーザーの不満で最大のものは、バージョンアップ時にアドオンが使えなくなることだろう。Mozilla Add-ons（AMO）が登録されているアドオンをチェックし、互換バージョンを自動的に更新するなど、ある程度の対策は施されているが、更新の対象にならない登録済みアドオンも当然存在する。そして、未登録のアドオンに対してはAMOも手の打ちようがない。 Firefoxユーザーの85％が何らかの

ユーザー体験上の目玉になるはずだったタブのアニメーション機能が、アドオンの互換性を損なうとして直前で実装を見送られることになり、バージョンアップによる進化が少し見えにくくなってしまったFirefox 8。Mozilla Japanのブログ記事でも、Twitter検索の追加を最初にもってきている。しかし、考えてみるとGoogle Chromeが毎回目立った機能を追加し続けているのかといえば、そうでもないわけで。地味なメジャーバージョンアップは、高速リリースサイクルの宿命かもしれない。 さて、例によってベンチマークである。比較対象は、以下のとおりWindows 7 SP1（64bit版）上で動作する32bit版のFirefox 7.0.1とFirefox 8.0（Beta 6）。新規プロファイルを初期設定のまま利用し、アドオンはすべて無効化するが、プラグインはShockwave Flash 1

はてなブックマークでの活動すらできないくらいに忙しく、ブログの更新をしないでいるうちに、Firefoxのバージョンが2つも上がってしまった。事前の予定どおりにリリースされ続けており、高速リリースサイクルは完全に定着したといえるだろう。 今回リリースされたのはFirefox 8だが、実は、1つ前のFirefox 7がリリースされた後、ベンチマークのデータだけはとってあった。せっかくなので、その結果を公開しておきたい。比較対象は、以下のとおりWindows 7 SP1（64bit版）上で動作する32bit版のFirefox 6.0.2とFirefox 7.0.1である。新規プロファイルを初期設定のまま利用し、アドオンはすべて無効化するが、プラグインはAdobe Flash Player 10.3（r183）だけを有効にした。なお、初期設定でハードウェア（HW）アクセラレーションが有効になってい