「ThunderbirdでPOP3のメールサーバーを利用している状態¹から、Microsoft 365のOutlookに乗り換える」といった移行シナリオでは、Thunderbirdに保存された古いメールをどうやって閲覧するかが課題となります。

最も簡単なのは「古いメールを保持した状態のThunderbirdを閲覧専用で残しておく」やり方ですが、この場合、古いメールを元に返信したり転送したりしようと思うと、その都度手作業でメールを新環境にコピーする必要が生じます。 新環境のメールアカウント²をThunderbirdに作成すれば、受信済みのメールをドラッグ＆ドロップで新環境に持ち越せますが、手動操作には操作ミスの危険がありますし、ユーザーが手順をなかなか実施してくれない恐れもあります。

そこでこの度、このような問題を解決する簡易的なソリューションとして、メールサーバー間でのメールの移行処理（コピー処理）を自動化し、組織単位でのメールシステム移行を支援するThunderbirdアドオン「Migrate Messages Between Accounts」を作成しました。 本記事では、このアドオンを使ったメールアカウントの移行の仕方を解説します。

当社ではGoogle Chrome用、Microsoft Edge用、Mozilla Firefox用（および、EメールクライアントのThunderbird用）拡張機能を多数開発・メンテナンスしています。 原則として開発した成果物のソースコードは公開しており、その多くはストアに掲載していますが、諸事情からストアには未掲載の物もあり、「具体的にどのような開発実績があるのか？」を知りたい方にとっては全体を把握しにくい状況にあるのは否めません。

そこで本記事では、現時点で各Webブラウザー製品にて使用可能な拡張機能を簡単な解説と共に列挙してみます。

去る7月21日、Firefoxの法人向け長期サポート版であるFirefox ESR¹の新しいメジャーバージョンである「Firefox ESR153（153.0）」がリリースされました。 1つ前のメジャーバージョンとなるFirefox ESR140のサポートは、10月13日に終了する予定となっています。

Firefox ESRは現在、ESR153とESR140の2つのバージョンが存在しており、8月18日には、それぞれのセキュリティアップデート版であるESR153.1とESR140.14がリリースされる見込みです。 ESR140のサポートは依然継続していますが、前述の通り10月13日にはサポートが終了するため、それまでの間にESR153へ更新することが強く推奨されます。

当社では、Firefox ESR140からESR153の間の変更点のレポートを公開しており、このレポート中では10のカテゴリーに分けて、法人利用に影響が及ぶと考えられる変更点を詳細に紹介しています。 この記事では、その中で特に影響度が大きいと考えられる項目を抜粋してご紹介します。

今月29日開催のクリアコード20周年記念Meatup（参加申し込みページ）に向けて準備を進めている結城です。

クリアコード年表で使用可能なOutlook用のOfficeアドインに続いて、Thunderbird用のアドオンも作ってみましたので、こちらで紹介いたします。

結城です。

先だって、当社のThunderbirdサポートにおいてお客様から以下のようなお問い合わせを頂きました。

• Thunderbird 140.5.0ESRが複数のメールフォルダーについて、ダウンロード済みであるはずのメールを、毎日再ダウンロードする。その結果、ローカルのプロファイルフォルダーのサイズが1日あたり1～2GBずつ増加し、ハードディスクの空き容量が逼迫している。
• 現象は特定のユーザーでのみ発生している。
• Thunderbirdのプロファイルを再作成して全メールを受信完了させた後でも、現象は引き続き発生する。
• メールサーバー側には特にエラーログは記録されていない。

本稿執筆時点でも完全解決には至っていませんが、お客様のご協力を頂いての調査の結果、原因の一端と回避方法は判明しました。 今回は、同様のトラブルでお悩みの方の参考になるよう、本件について現時点で分かっていることをご紹介します。

結城です。

Firefox 149での開発者向けの変更点情報に記載されたトピックの1つに、拡張機能内のリソース（URLがmoz-extension://～となる物）を読み込んだタブへのスクリプトの動的な注入操作の廃止があります。 この変更は現在は開発版でのみ有効化されており、Firefox 152以降でリリース版でも有効化される旨が決定しています。 今のところは隠し設定を切り替えれば従来の動作に戻せます¹が、いずれはこの隠し設定も廃止されて、拡張機能内のリソースに対してはスクリプトの動的な注入操作が恒久的に不可能になるはずです。

筆者が開発している拡張機能「Tree Style Tab（TST）」や、そこで使用しているライブラリーを共用している当社製の他の拡張機能でも、一部の機能が動かなくなる影響が出ていたため、この2ヵ月ほどの間に対応のための改修を行いました。 この記事では、「そもそも、それらの拡張機能ではなぜスクリプトの動的な注入を行っていたのか」「なぜスクリプトの動的な注入が禁止されるようになったのか」「変化に拡張機能側でどのように対応したのか」を解説します。

結城です。

このブログでは2018年に、Firefoxの不具合を修正したり新機能を追加したりといったコントリビューションを行う際のパッチの作り方と、Phabricatorというツールを使ってコードレビューを受ける手順を紹介しました。

2026年現在では、既定のバージョン管理システムがMercurialからGitに移行した他、Phabricatorを使うためのツールのインストール手順が簡素化され、Firefoxへパッチを提供するためのハードルが以前よりも低くなっています。 この記事では、Firefoxへの不具合報告の仕方の解説と不具合の原因調査および修正の仕方の解説に続くシリーズ完結編として、2026年の状況に基づいてFirefoxに不具合を修正するパッチを提供する手順をご紹介します。

結城です。

このブログでは過去何度か、FirefoxやThunderbirdの不具合の原因調査や修正の事例をご紹介してきました。 ですが、原因の見つけ方や修正方針の検討の詳細な所はあまり言語化してきていなかったように思われます。

この記事では、Firefoxへの不具合報告の仕方の解説の続編として、Firefoxを使用していて遭遇した不具合の原因を特定し、経緯や事情を調査して適切な修正内容をまとめる所までの詳細な流れをご紹介します。

結城です。

Firefoxを開発しているMozillaプロジェクトでは、ソースコードのバージョン管理システムをMercurialからGitに移行し、GitHubでホスティングしていく方針が2023年に示されました。 その後、実際に移行が進んで、本稿執筆時点（2026年1月）ではソースコードの入手はGitHubのリポジトリーから行うのが規定となっています。 その一方で、不具合報告の受け付け・管理のためのイシュートラッカーとしては、GitHubのイシュートラッカーではなく、Mozillaプロジェクト専用のイシュートラッカーであるbugzilla.mozilla.org（以下、BMO）が依然使われています¹。

このブログでは、Firefoxの不具合を修正したり新機能を追加したりといったコントリビューションを行う際のパッチの作り方を2018年に紹介しましたが、当時の記事は既に誰かによって報告された不具合へのパッチ提出が前提で、自分が見つけた不具合を報告する場面の説明は含まれていませんでした。 パッチ提出の流れには当時と比べ変化があったため、その点を紹介する記事を執筆したいのですが、まずはその前段階として、この記事では具体的な事例を参照しつつ、BMOを用いたFirefoxの不具合報告の仕方をご紹介します。

結城です。

このブログではこれまで、2015年と2017年にWindowsでのFirefoxの独自ビルドの作成方法をご紹介しました。

本稿執筆時点では、既定のバージョン管理システムがMercurialからGitに移行していたり、MozillaBuildやブートストラップスクリプトによる自動初期化の仕組みが進歩していたりして、また状況が変わっています。 この記事では、2026年1月現在においてWindows用のNightlyおよびFirefox ESR140の独自ビルドを作成する手順をご紹介します。