• 報告の流れ（おさらい）
• 修正を提案する
  • Phabricatorへのログイン
  • moz-phabコマンドのインストール（初回のみ）
  • APIキーの設定（初回のみ）
  • コミットとレビューリクエストの作成
  • レビュアーを探して指名する
• パッチ提出後にすること
  • パッチを修正する
• ランド（マージ、あるいはチェックイン）を依頼する
  • 承認された後でパッチをさらに修正する
  • 撤回されたパッチを修正する
  • 影響度の大きい問題の修正の場合
• まとめ

結城です。

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

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

報告の流れ（おさらい）

前々回記事・前回記事の冒頭において、オープンソース開発プロジェクトへの外部からの関わり方として以下の3段階がある旨を述べました。

1. 不具合を報告する。
2. 原因を調査して明らかにする。
3. 不具合を修正するパッチを提供する。

本記事では、このうち3の部分について、2022年に筆者が実際に報告し2025年末に解決となったBug 1762249の事例を参考にして説明します。

この記事では、「WindowsでのFirefoxのビルド手順の解説に従ってFirefoxのリポジトリーをローカルにcloneしていて、そのリポジトリー上で修正のための変更を行ったけれどもまだcommitはしていない」という状況から説明を始めています。 「どのような不具合だったか」については前々回記事で、「どのように修正したか」は前回記事で詳しく説明しているので、背景を知りたい方はまず前々回記事からご覧下さい。

修正を提案する

前回記事では、自分が報告したFirefoxの不具合について、原因を突き止め、実装の修正を手元で行ってみました。 実装を修正して、回帰テストも用意できたら、いよいよ修正の提案です。

本稿執筆時点では、Firefoxのソースコードの中央リポジトリーはGitHub上のGitリポジトリーとなっています¹。 しかし、不具合の報告の受け付けにGitHubのイシュートラッカーではなくBMO（bugzilla.mozilla.org）という別の仕組みが使われているのと同様、修正提案の受け付けやコードレビューにも、GitHubのプルリクエストではなくPhabricatorという別の仕組みが使われています²。 Phabricator経由で提出した変更の提案は、Mozillaでは伝統的な呼び方に則って「パッチ」と呼ばれます。

Phabricatorを使ったパッチのレビューの流れ自体は2018年時点と変わっていませんが、バージョン管理システムがMercurialではなくGitに移行し、Phabricatorを使い始めるための準備手順にも変化があったため、ここで改めて一通りの手順を紹介することにします。

なお、以下の説明はすべて、WindowsでのFirefoxのビルド手順の解説に従ってビルドを行えて、且つ、前々回記事の解説に従ってBMOにログインできる状態となっていることを前提とします。 準備がまだ整っていない場合は、各記事を参照して準備を整えておいてください。

Phabricatorへのログイン

MozillaのPhabricatorは https://phabricator.services.mozilla.com/ でアクセスできます。 ページ上部の「Log In」ボタンをクリックして、ログインを試みます。

すると、BMOのアカウントでのログイン又は登録を促すボタンが表示されますので、これをクリックします。

BMOにログイン済みであれば、PhabricatorにBMOのアカウント情報へのアクセス許可を求める画面に遷移しますので、「Allow」ボタンをクリックします。 （未ログイン状態の時はまずログインを求められます。ログイン後にトップページに遷移してしまった場合は、Phabricatorのページでのログイン操作からやり直してください。）

BMOでの承認後、Phabricatorに再び画面遷移します。

このとき、BMOのアカウントで多要素認証を有効化していないと、認証に失敗してPhabricatorがエラーメッセージを表示します。 メッセージ中の「preferences」というリンクからBMOの設定画面に遷移できるので、多要素認証の設定³を行ってから再度Phabricatorのログイン操作をやり直してください。

Phabricatorを初めて利用する場合は、ここでPhabricator上でのアカウント登録を促されますので、表示用のアカウント名と本名をそれぞれ入力し、「Register Account」ボタンをクリックしてアカウントを登録します。

moz-phabコマンドのインストール（初回のみ）

パッチの提出は、Phabricator操作用のコマンドラインツールであるmoz-phabで行います。 まず、clone済みのFirefoxのGitリポジトリー内で ./mach install-moz-phab を実行して、moz-phab コマンドをインストールします。

なお、WindowsでMozillaBuildを使用している場合、moz-phabのインストール過程で以下のエラーが出る場合があります。

URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1010)>
Run moz-phab again with '--trace' to show debugging output

これは、moz-phabがWindowsの証明書ストアを使用してくれないために起こるエラーです。 この場合、~/.bash_profile に以下のように追記して、MozillaBuildに含まれる証明書ストアを使うよう明示的に設定する必要があります。

export SSL_CERT_FILE=/usr/ssl/certs/ca-bundle.crt
export REQUESTS_CA_BUNDLE=/usr/ssl/certs/ca-bundle.crt

また、moz-phabが ~/.local/bin にインストールされた場合、パスが通っていないのでそのままでは moz-phab コマンドを実行するのに不便です。 この場合、~/.bash_profile に以下のように追記してパスを通しておきます。

export PATH="$HOME/.local/bin:$PATH"

~/.bash_profile を編集したら、MozillaBuildのシェルを開き直して作業を続行します。

APIキーの設定（初回のみ）

moz-phab コマンドが使える状態になったら、moz-phab install-certificate を実行します。 すると、端末に以下のように表示され入力待機状態になります。

$ moz-phab install-certificate
LOGIN TO PHABRICATOR
Open this page in your browser and login to Phabricator if necessary:

https://phabricator.services.mozilla.com/conduit/login/

Paste API Token from that page:

表示されたURLにブラウザーでアクセスする⁴と、BugzillaとPhabricatorを連携するためのAPI Tokenが表示されます。 API Tokenをクリップボードにコピーして、コンソールのプロンプトに貼り付けて入力しEnterキーを押すと、設定が保存されて moz-phab コマンドでのパッチ提出およびレビュー依頼が可能になります。

コミットとレビューリクエストの作成

Firefoxへのパッチ提出は、すべてBMO上のBugと紐付ける必要があります。 Bugに関連付かないパッチは提出できないため、もし真っ先にソースコードを編集して不具合を修正する部分から入ってしまったのであれば、前々回記事を参考にして、まず「こういう不具合がある」と報告する必要があります。 もし既存の報告がある既知の不具合なのであれば、それに関連付けてのパッチ提出も可能です。

「このBugにパッチを提出する」ということがはっきりしたら、修正のための変更を以下の要領で手元のGitリポジトリーにコミットします。

$ git stash # 変更を一旦退避
$ git switch main && git pull # 最新の状態にリポジトリーを更新
$ git stash pop # 退避した変更を再適用
$ git switch -c fix-bug-1762249 # Bugの番号を含めてブランチを作成する
$ git add browser/base/content/test/general/browser_bug1762249.js # 追加した自動テストを明示的にgit addするのを忘れずに！
$ git commit -a

このとき、コミットメッセージは以下の書式で記述する必要があります。

Bug （Bugの番号） - （Bugの概要となる一行説明）

以下、Bugやパッチの詳細な説明...

moz-phabは、このコミットメッセージの記載内容から対応するBugを自動的に特定し、そこにパッチを関連付けて提出してくれるようになっています。 書式やBug番号を間違えると、Phabricator上のパッチとBugとが期待通りに関連付けられないこともあるので、入力は気をつけて行って下さい。 例として、今回のパッチ提出にあたって実際に筆者が書いたコミットメッセージを以下に示します。

Bug 1762249 - Accept already-discarded owner tab r?Gijs

元のBugは「アンロード済みのタブを親に指定するとタブを開けない」という問題なので、このコミットはそれを修正するものとして、「アンロード済みのタブを親タブとして受け付けるようにする」というコミットメッセージとしました。

コミットメッセージ末尾の r？Gijs は、レビュアーの指定です。 一行説明の末尾に r?（レビュアーのPhabricatorアカウント名） と付け足すと、パッチ提出と同時にレビュアーを指定することができます。 ただ、後述しますが、レビュアーはパッチの提出後にPhabricatorのUI上からも指定できるので、この時点で無理にレビュアーを指定する必要はありません。 初めてのパッチ提出で勝手が分からない場合は、ここではレビュアー指定はせずに先に進んで下さい。

また、この例では変更がごく小規模で単純だったため、3行目以降の詳細説明は省略しています。 その変更だけを見ても変更の趣旨が分かりにくい複雑な背景を持つ修正の場合は、3行目以降で詳しく説明を加えるとよいかもしれません。 ただ、詳細な背景は番号で参照しているBugを見れば分かるため、筆者は詳細説明は省略することが多いです。

ローカルのGitリポジトリーに変更をコミットできたら、moz-phab コマンドに submit サブコマンドを指定して実行し、Phabricatorにパッチを送信します。

$ moz-phab submit

すると、

送信完了後に、先ほどコミットした内容を git log で確認してみると、以下のように Differential Revision: という行が追加されていることに気が付くでしょう。

Bug 1762249 - Accept already-discarded owner tab r?Gijs

Differential Revision: https://phabricator.services.mozilla.com/D142644
...

この行は、レビュー結果を承けてパッチを修正・再提出する際に必要になります。 また、この行に記載されているURL https://phabricator.services.mozilla.com/D142644 をブラウザーで開くと、Phabricator上でレビューリクエストを参照することができます。 以後、レビュアーとのやりとりはこのページで行うことになります。

レビュアーを探して指名する

先の例ではコミットメッセージでレビュアーを指名してパッチを提出しました。 また、後からPhabricatorのUI上でレビュアーを指定することもできると述べました。 では、その肝心のレビュアーには一体誰を指名すればよいのでしょうか？

これは端的には、変更を行った箇所の実装を過去にレビューした人を指定するのが無難です。

前回記事で原因の調査と変更が必要な箇所の特定を行いましたが、このとき、変更対象の箇所をSearchfoxで表示して行番号の左のグレーの領域にポインターを載せると、その行の由来となったコミットの詳細が表示されます。 ここでコミットメッセージの末尾に r=（アカウント名） という記述⁵があれば、その人がレビュアーです。

コミットメッセージにレビュアー名の指定がない場合は、「Phabricator revision Dxxxxxx」と書かれた部分をクリックしてPhabricatorのレビューのやり取りを確認しましょう。 「Details」の「Reviewers」という欄を見れば、レビュアーが誰だったのかが確実に分かります。

今回の変更箇所の場合は、Firefoxのタブブラウジング関係の実装に深く関わっておられるGijs Kruitbosch氏がレビュアーだったようです。 ということで、筆者はGijs氏をレビュアーに指名してみました。

コミットメッセージにレビュアー指定を含めなかった場合は、パッチ提出後に改変されたコミットメッセージに記録されていたPhabricatorのURL（今回であれば https://phabricator.services.mozilla.com/D142644 ）をブラウザーで開き、ページ末尾の入力欄の「Add Action...」で「Change Reviewers」を選択して、表示された入力欄にレビュアー名を入力します。

最後に「Submit」ボタンを押すと、レビュアーの指定がPhabricatorに反映されます。 「Submit」ボタンを押すまで、入力中の情報はあなたのブラウザー上で未送信状態のままとなりますので、最後に「Submit」するのを忘れないでください。

なお、変更対象の実装が昔からある部分の場合、その部分の変更をレビューした人が既にMozillaプロジェクトから離れていることがあります。 その場合、当該ファイルや親ディレクトリーの変更履歴を見て、最近行われた変更のレビュアーを参照するとよいでしょう。

パッチ提出後にすること

パッチを修正する

レビュアーによってパッチがレビューされたり、botによって自動的に検証されたり⁶した結果、Phabricator上で修正箇所を指摘されることがあります。 その場合、指摘に従ってパッチを修正し再提出する必要があります。

今回の事例（前回記事の通りに行った修正の提案）では、以下のような指摘を受けました。

• このパッチではif文にANDで列挙する条件を1つ増やしているが、openerBrowser && openerBrowser.browsingContext はオプショナルチェーン演算子を使って openerBrowser?.browsingContext と簡潔に書ける。
• 回帰テストはコメントの指示の通りに、このディレクトリーには置かずに専用のディレクトリーに置いて欲しい。また、ファイル名はBugの番号ではなく、テスト対象の挙動を説明する物にして欲しい。
• 回帰テストにライセンスヘッダーと "use strict" の記述を足して欲しい。また、テスト用ウィンドウを閉じる方法はもっと安全な方法を使って欲しい。

パッチ提出時のコミットが1つだけだった場合、パッチの修正は以下の要領で行うのが最も簡単です。

1. 当該パッチの作成のために用意したブランチに切り替える。
2. 指摘事項を反映する。
3. 変更箇所を git add でステージングする。
4. git commit --amend で変更を最後のコミットに反映する。
5. moz-phab submit を実行して、パッチを再提出する。

パッチの再提出時には、同一のレビューリクエストの更新であることを示すため、コミットメッセージに Differential Revision: の情報を含める必要があります。 パッチ提出後に確認したとおり、moz-phab submit の実行時に最新のコミットのメッセージの末尾には自動的に Differential Revision: の情報が追加されていますが、これを追加のコミットのメッセージに書き忘れると、既存レビューリクエストの更新にならずに新しいレビューリクエストが作成されてしまいます。 なので、追加のコミットをするときは必ず、パッチ提出時のコミットから Differential Revision: を書き写すようにしてください。 git commit --amend は最新のコミットのメッセージをそのまま引き継ぎまので、この手順であれば Differential Revision: を手動で入力せずに済みます。

git commit --amend を使うとローカルリポジトリーのコミットが上書きされるため、ローカルでは「修正前のパッチ」を確認できなくなります。 パッチの過去のリビジョンを確認したい場合は、PhabricatorのUIの「Revision Contents」欄の「History」タブを参照して下さい。

moz-phab submit でパッチを再提出したら、Phabricator上でその修正に対応するコメントの「Done」にチェックを入れ、レビュアーのコメントに返信します。 チェック状態の変更や入力したコメントは、それだけだとあなたのブラウザー上に保存されているだけなので、最後に「Submit」ボタンをクリックして送信するのを忘れないでください。

パッチを再提出すると、Phabricatorで指定したレビュアーに通知が届くようです。 再度レビューしてもらえるのをおとなしく待ちましょう。

今回の事例では、この段階でこちらの作業が中断してしまい、なんと3年後になってようやくパッチを修正することができました。 その間にFirefox自体の設計の見直しが進んだ結果、メソッド名が変更されたりファイルの位置が変更されたりして、パッチは当初の物をそのまま当てることはできなくなっていたため、改めて原因箇所を調べ直して、同じ趣旨の修正になるように改めてパッチを作り直す必要がありました。 （幸い、自動テストの方はファイルの置き場所を変えて微修正する程度で済みました。）

ランド（マージ、あるいはチェックイン）を依頼する

レビュアーによってパッチに問題がないと判断された場合、以下のようにAcceptedのマークが付きます。

この状態になったら、パッチのランド⁷が可能になります。 Mozilla Phabricator User GuideのLanding Patchesの項には、パッチのランドにはLandoというシステムを使うように書かれていますが、これはいわゆるコミット権を持っているMozillaプロジェクトの開発者を想定した文章です。 コミット権が無い外部の協力者として関わっている段階では、このシステムは利用できません。

自分にはコミット権が無い場合は、BMOで他の人に依頼する必要があります。 今回は、筆者は以下のようにコメントして関係者の反応を待つことにしました⁸。

The patch has been reviewed and accepted. I have no authority so could anyone check-in it?

（パッチはレビューされ承認されました。私には権限が無いため、どなたかチェックインしてくれませんか？）

そうしたところ、半日ほどして変更対象のモジュールの開発を多く手がけている方がパッチを代わりにランドして下さいました。

Pushed by dgottwald@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/e8d015b620ce https://hg.mozilla.org/integration/autoland/rev/112e58af4ddc Accept already-discarded owner tab r=Gijs,tabbrowser-reviewers,dao

この https://hg.mozilla.org/integration/autoland というのは、パッチの妥当性を検証するためのCI用ブランチです⁹。 ここで他のパッチと一緒に自動テストが実行され、問題や後退バグが発生していないことが確認された時点で、ようやくメインの開発ブランチである https://hg.mozilla.org/mozilla-central にパッチが投入されます。 パッチが無事にメインの開発ブランチに投入されると、以下のようにリビジョンのURLを示したコメントでそのことが知らされます。

https://hg.mozilla.org/mozilla-central/rev/112e58af4ddc

承認された後でパッチをさらに修正する

筆者は未経験ですが、場合によっては「Acceptするけど、こことここだけは修正しておいてね」と、Phabricatorのレビューリクエストに Accepted のマークが付くと同時にパッチの修正も求められることがあるようです。 この場合、パッチは修正して再提出する必要があります。

パッチを再提出すると、Phabricatorのレビューリクエストのマークが以下のように変わります。

レビューで指摘があったということは、修正後のパッチに再度のレビューが必要そうにも思われますが、ここでは一度 Accepted されているため、よほどの大きな変更でも無い限りは再レビューの必要はないようです。 自分で修正できたと判断できたら、パッチの再提出後にそのままパッチのランドを依頼してしまいましょう。 ただし、指摘された箇所は全て「Done」にチェックを入れて、最後に「Submit」するのを忘れないでください。

撤回されたパッチを修正する

一旦ランドされたパッチでも、CIでの自動テストの失敗によって撤回（Backout）される場合があります。 このような場合、Phabricator上のパッチは既に一旦Closedになってしまっているため、そのままでは修正を継続できません。

FAQによると、このようなケースでは以下の手順でパッチのレビューリクエストをReopenする必要があります。

1. ページ最下部のコメント入力欄までスクロールする。
2. 「Add Action...」のドロップダウンリストを開き、「Revision Actions」配下の「Reopen Revision」を選択する。
3. 「Submit」をクリックしてアクションを確定する。

この操作を行うとパッチが「Accepted（レビュー完了済み）」の状態に戻りますので、git commit --amend でパッチを修正するなどして、再度 moz-phab submit し、またレビュアーの反応を待つことになります。

影響度の大きい問題の修正の場合

セキュリティに関わる問題や、ユーザー体験に深刻な影響を与える問題の場合、この後メインの開発ブランチからベータ版や通常リリース版のブランチへ変更をupliftしてもらう必要があります。

upliftの必要があるかどうかは、Mozillaの開発者が判断します。 日本語圏での使用に特有の不具合など、英語圏の人には影響度が分かりにくい問題の場合は、コメントでその旨を詳しく説明して説得する必要があります。 理解を得られたら、Mozillaの開発者によってBMOでのpriorityやseverityが引き上げられ、パッチがupliftの対象になります。

メインの開発ブランチと同じパッチを適用できる場合はそのまま処理してもらえるのですが、運が悪いと、メインの開発ブランチとは別にベータ版やリリース版のブランチ専用にパッチを作り直す必要が生じる場合もあります。 その場合、Mozillaの開発者から「ベータ版ブランチ用にパッチを作って」などと依頼されることがありますので、ローカルリポジトリーのブランチを切り替えてパッチを作成し、通常の手順と同じ要領でパッチを提出しましょう。

なお、Bugの状態がP1やP2になっていて、ベータ版なども影響を受ける重大な問題であるにも関わらず、パッチがすぐにはupliftされない場合、upliftが忘れられている可能性もあります。 その時は、BMOで「この修正のupliftはまだでしょうか？」等コメントしてみるとよいでしょう。

まとめ

以上、Firefoxの不具合を修正するパッチを提出する手順をご紹介しました。

開発に使われるリポジトリーがMercurialからGitに移行したことで、Firefoxへのパッチ提供はかなりやりやすくなったと言えます¹⁰。 とはいえ、自分の手元で行った修正をとりあえずpushして開発元に提案できるという、GitHubでのプルリクエストのやり方に比べると、BMOとPhabricatorを行き来しなくてはならないFirefoxへのパッチ提供は、尻込みする人も多いのではないでしょうか。 筆者としては、この記事がFirefoxへのパッチ提供を試みてみたい人のための一助となることを願っています。

株式会社クリアコードは、FirefoxやThunderbirdの法人運用において生じた様々な問題について、ソースコードレベルの調査も含めたサポートを行うサービスを有償でご提供しています。 また、FirefoxやThunderbird自体の不具合が原因だった場合、開発元に報告を行い、可能な場合はパッチも提供しています。 FirefoxやThunderbirdの運用で何かお困りの企業の運用担当者さまは、お問い合わせフォームよりお問い合わせ下さい。

ツイートする

フォローする