資料ダウンロード

ククログ

株式会社クリアコード > ククログ > Firefoxの不具合の報告の手順（2026年版）

Firefoxの不具合の報告の手順（2026年版）

結城です。

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

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

報告の流れ

一般的に、コントリビューションを広く募っているオープンソース開発プロジェクトでは、プロジェクト外の人がソフトウェアの不具合に遭遇したときに、プロジェクトの問題を解決する方法として以下の3段階の関わり方が可能です。

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

本記事では、このうち1の部分について、2022年2に筆者が実際に報告したBug 1762249の事例を参考にして説明します。

報告したい問題の詳細を明らかにする

多くの場合、ソフトウェアを使っていて問題に遭遇したときには、まず「変だ！」「動かない！」「困った！」と感じるものでしょう。 ただ、それをそのまま「なんか変なんだけど！」とだけ報告しても、解決には繋がりません。 解決に繋がるように報告するためには、「自分が遭遇した問題がどういう問題なのか」を自分で調べて明らかにして、ソフトウェアの開発者の側でも把握できるように説明する必要があります。

Bug 1762249の時は、筆者が作成したFirefox用アドオンに寄せられた不具合報告が発端でした。 「筆者が作成したアドオンと、とある別のアドオンとを併用した際に、別のアドオンの方の機能でタブが開かれるはずなのに、タブが開かれなくなってしまう」という報告でしたが、両アドオンの動作や内部の実装を詳しく調べてみたところ、これらのアドオンの設計自体には問題がなく、Firefoxのアドオン向けAPI「WebExtensions API」がドキュメントの記載どおりに動作していれば、問題は発生しそうにありませんでした。

ただ、Firefox自体のエラーコンソールを見ていたところ、アドオンがタブを開くためのWebExtensions APIを呼び出している処理の所で、Firefox内部で例外が発生している様子は窺えました。 例外が発生したときのAPIの呼び出し方を調べたところ、「メモリー消費量の節約のためにFirefoxによってアンロードされたタブがあるときに、そのタブから開かれたものとして新しいタブを開こうとしている」という場面であったことが分かりました。 そこで、同様の条件で当該APIを呼び出すだけの最小のアドオンを実際に作成して、動作を確認したところ、果たしてAPI呼び出しの部分で例外が発生し、確かにタブを開けない結果となりました。

（正常時と異常時のbrowser.tabs.create()の振る舞いの差を示した図。openerTabIdで参照されたタブがアンロードされていない場合はタブが開かれるが、アンロードされていた場合はタブを開けずに例外を投げる。）

このことから、報告を受けた問題の根本的な原因は「メモリー消費量の節約のためにアンロードされたタブがあるときに、そのタブから開かれたものとして新しいタブを開くようFirefoxに指示すると、Firefoxがタブを開けずに例外を投げる」という、WebExtensions API自体の不具合であると判断できます。 通常リリース版のFirefoxだけでなく、Firefoxの最新の開発版であるNightly3でも最小のアドオンを動作させてみましたが、結果は同様でした。 また、普段から常用しているプロファイルだけでなく、新規プロファイル4でも同じ結果となりました。

また、WebExtensions APIはGoogle Chromeの拡張機能向けAPIと互換性を持つように設計・実装されています。 そこで、確認のためにGoogle Chromeにおいて同じ条件下で問題のAPIを使用してみたところ、Chromeでは特に例外にはならず、タブが期待通りに開かれる結果となりました。

問題の詳細を整理する

前項のような時系列順の長文は、読み手の認知負荷が高く、不具合報告としてそのまま開発者に見せるのには適していません。 報告を受理されやすくするには、開発者がスムーズに要点を掴めるように報告の内容を整理することが大事です。

不具合の報告は一般的に、「再現手順」「期待される結果」「実際の結果」の3点で整理するのが有効です。 前項の内容であれば、以下のように整理できます。

  • 再現手順：タブを開くためのAPIである browser.tabs.create() を、 openerTabId パラメーターにアンロード済みのタブのIDを指定して実行する。
    • この処理だけを行うテストケースのアドオンを実際に作成してみただけでも、問題は再現できる。
    • この問題は最新のNightly5でも、新規プロファイルでも再現する。
    • 検証はWindowsで行い、他のOSでは試していない6。
  • 期待される結果：タブが開かれる。
    • 同様の場面でGoogle Chromeはそのような結果となる。
    • WebExtensions APIの仕様は基本的に、Google ChromeのAPIと互換性があることが期待される。
  • 実際の結果：タブが開かれずに例外が発生する。
    • 仕様に記載されていない挙動である。
    • Google Chromeとの間でAPIの振る舞いに互換性がない。

開発者の手元で問題を容易に再現できる場合、開発者側でデバッグ用ツールなどを用いてより詳しい調査を行えるため、原因の特定がスムーズに進む傾向があります。 また、再現できないとしても、現象の発生に至る経緯や発生時の状況が分かれば、原因を推測しやすくなります。 再現手順をまとめる際に気をつけるべきこととしては、以下のような点があります。

  • アドオンのインストールや設定の変更など、何らかの準備をしないと再現できない種類の問題の場合は、新規プロファイルで問題を再現させる場合に事前に必要な設定や準備の仕方を書き出しておきます。
  • もし再現手順の中にUIの操作が含まれる場合は、「このボタンをCtrlキーを押しながら左クリックする」「このメニューを開いて、このラベルの項目をクリックする」「この入力欄にこの文字列を入力して、Enterキーを押す」といった要領で、実際に自分が行った操作の仕方7を具体的に書き出しておきます。
  • 今回はWebExtensions APIの呼び出し方がポイントになるので、再現手順は「WebExtensions APIをどういう順番で呼び出せば再現できるか」という観点でまとめるとよさそうです。

再現手順や実際の結果を効率よく説明する上で有用なのが、最小のテストケースです。 テスト用のHTMLファイルやスクリプトなど、開発者の手元でファイルを開くだけで問題を再現できるような資料や、スクリーンショットやスクリーンキャストなどの画像・映像資料8があると、細かな操作手順の違いなどによる認識の齟齬の発生を防げます。 今回の事例では「検証用に作ってみた、その処理だけを含むアドオン」が既にあり、これが最小のテストケースだと言えます。

また、整理の際は期待される結果と実際の結果も明確化させておきましょう。 「本当はどうなっていて欲しいのか」「現状ではどうなっているのか」が不明瞭だと、報告を受けた開発者は「で、何が問題なの？」と戸惑うことになります。 目指すべきゴールが不明瞭だと、「どう修正するべきなのか」「どこまで修正するべきなのか」などの点で議論が発散して迷走してしまうこともあります。

一通り整理できたら、この問題を端的に説明する要約となる言い方も考えておきます。 今回であれば以下のような言い方が考えられます。

  • アンロードされたタブを openerTabId に指定したときに、WebExtensions APIの tabs.create() が失敗する。
  • WebExtensions APIの tabs.create() において、アンロードされたタブを openerTabId に指定してタブを開くことができない。
  • WebExtensions APIの tabs.create() でタブを開くときに、openerTabId がアンロードされたタブのIDだとエラーになる。

BMOで既存の報告を探す

不具合の情報を整理できたら、報告の前に、同じ不具合の報告がもう行われていないかどうかを調べます。 前述の通り、Firefoxの不具合報告はMozillaプロジェクト専用のイシュートラッカーであるBMOで管理されています9ので、ここに報告があるかどうかを調べましょう。

BMOのページには上部に検索窓がありますが、ここからの検索では解決済みの報告10が除外されてしまいます。 同じ報告がないかどうかを漏れなく調べるためには、ページ上部のAdvanced Searchの方から辿って、「Status:」欄（報告の現在の取り扱い）と「Resolution:」欄（報告がどのように解決されたか）のリストをShift-クリックやCtrl-クリックで全選択状態にしてから、「Summary」欄にキーワードを入れて検索しましょう11。 今回であれば、筆者はキーワードを tabs.create discarded と指定して検索しました12。

（BMOで既存の報告を検索する様子のスクリーンショット。「Summary」欄に検索語句を入力し、「Status」欄と「Resolution」欄はすべての候補を選択した状態になっている。）

筆者が報告を行った時点では、この方法での検索結果に表れる報告はいずれも今回の不具合とは別の件に関する物である様子でした。

このような場合に、「自分の探し方が不充分なせいで見つからなかったのか、それとも本当に同じ事例の報告がまだ無いのか」を判断するのは困難です。 報告者の考え方や言葉の選び方次第では、まったく別のキーワードでなければ報告を見付けられない可能性はあります。 ただ、既存の報告を見付けることに躍起になりすぎて疲弊して報告を諦めてしまっては、本当にまだ報告されていない不具合だった場合には本末転倒です。 そのため、筆者は30分程度を目安として、自分なりに工夫して同様の報告を探してみて、それでも見つからなければ、「自分の切り口からの報告はまだ無いのだろう」と判断して報告するようにしています13。 このような考え方であれば、同じ切り口での報告を重複させてしまいにくいですし、また、もし違う切り口で同じ不具合の報告が既にあって、そちらへ誘導される形でクローズされた場合でも、「その切り口で考えて検索した他の人にとっての誘導経路を整備した」という意義は残ります。

以上のように考えて、筆者は本件を新しい不具合として報告することにしました。

BMOのアカウント作成

BMOで不具合を報告したり既存の報告にコメントしたりするには、アカウントの作成が必要です。 まだアカウントが無い場合は、ページ右上の「Log in」をクリックして表示されるポップアップの最下部の「Create an Account」からアカウントを作成します。 （BMOのトップページで最上部の「Log in」をクリックしてポップアップが表示された状態のスクリーンショット。ポップアップ最下部に「Create an Account」と書かれたリンクが表示されている。）

アカウント作成画面でメールアドレスを入力し、利用者向けのエチケットやガイドラインへの同意のチェックをONにして「Create Account」ボタンをクリックすると、アカウント作成の確認メールが届きます。 （BMOのアカウント作成画面のスクリーンショット。いくつかの説明が表示され、その最後に「Create an account」という見出しがあり、配下にはメールアドレス入力欄と、利用者向けエチケットやガイドラインへの同意を求めるチェックボックス、「Create Account」というラベルの送信ボタンがある。） （BMOから届いたメールのスクリーンショット。本文中にBMOの認証ページのURLがある。） メールに記載されているURLからアカウント作成の続きの作業を行うためのページにアクセスし、本名（省略可能）とパスワードを入力して「Create」ボタンをクリックすれば、アカウント作成は完了です。 （BMOのアカウント作成確認画面のスクリーンショット。本名の入力欄と、パスワード入力欄、パスワードの再入力欄があり、その下に「Create」というラベルの送信ボタンがある。）

GitHubアカウントとの連携

BMOのアカウントを作った後は、同じメールアドレスを使っているGitHubアカウントでもログインが可能です。 GitHubと連携するには、ログイン後のBMOの画面右上に表示されている人影のアイコン14の部分をクリックして、表示されるポップアップから「Log out」を選択して一旦ログアウトし、再度「Log in」をクリックして「Log In with GitHub」をクリックします。 （BMOのページ最上部右のアイコンをクリックしてポップアップが表示された状態のスクリーンショット。ポップアップ最下部に「Log out」と書かれたリンクが表示されている。） （ログアウトしてからBMOのページ最上部の「Log in」をクリックしてポップアップが表示された状態のスクリーンショット。ポップアップ内に「Log In with GitHub」というラベルのボタンがある。）

すると、（GitHubに未ログインであればログインを求められた後で、）BMOにGitHubアカウントの情報へのアクセス許可を求める画面に遷移します。 「Authorize bugzilla-mozilla-org」をクリックして許可を与えれば、OAuthアプリとしてBMOがGitHubのアカウント情報に登録され、以後はBMOのアカウントのパスワードを入力せずともログインできるようになります。

（GitHubの、BMOをOAuthアプリケーションとして認証しアカウントの情報へのアクセスを許可する画面のスクリーンショット。アプリケーション名が「bugzilla-mozilla-org」と表示されていて、「Authorize bugzilla-mozilla-org」というラベルのボタンがある。）

BMOアカウント自体の多要素認証

BMOのアカウント設定では、TOTPを使った多要素認証も設定できます。 Firefoxへのパッチ提供時のコードレビューに使われるPhabricatorというシステムを利用するには、BMOアカウントの多要素認証の設定が必須となっています。 Firefoxへのパッチ提供にも興味がある場合は、ログイン成功後に多要素認証の設定を有効化しておきましょう。

なお、本稿執筆時点では、BMOアカウントの多要素認証を有効化していると、GitHub連携でのBMOへのログインができなくなるという制限があります。 筆者はFirefoxへのパッチ提供を行う場合があるため、BMO側の多要素認証を有効化し、GitHubとの連携は使っていない状況です。

報告の作成

報告したい情報を整理できたら、いよいよ報告です15。

BMOにログインした状態でページ上部の「New Bug」のリンクを辿ると、対象プロダクトを選択する画面に遷移します。 BMOでは、ここで大まかな対象を絞り込んでから実際の報告を行います。

（BMOのページ最上部の「New Bug」ボタンと、それをクリックした後に表示される対象プロダクト選択画面のスクリーンショット。）

対象プロダクトは、Firefox内部の設計に詳しくない場合は「Firefox」を選択するほかありませんが、分かる場合はより細かい単位で適切そうな選択肢を選びましょう。 報告の内容自体がきちんと書けていれば、間違ったプロダクトを選択していても、分かる人が適切なプロダクトを選択し直してくれます。 今回の例はWebExtensions APIの不具合なので、「WebExtensions」を選択しました。

プロダクトを選択したら、報告の内容を書く画面に遷移します。

（BMOで「New Bug」をクリックして表示される対象プロダクト選択画面からプロダクトを選択した後の画面のスクリーンショット。いくつかの入力欄が並んでいる。）

この画面には、本稿執筆時点では以下の入力欄があります。

  • Summary（要約）：先程整理したときに考えた「問題を端的に説明する言い方」を書きます。今回は「アンロードされたタブを openerTabId に指定したときに、WebExtensions APIの tabs.create() が失敗する」ということで、それを英訳して「tabs.create() fails when it is called with "openerTabId" for a discarded tab」としました16。
  • Categories（カテゴリー）
    • Component（コンポーネント）：より詳細な単位の対象分野を選択します。分からない場合は、選択肢の下にある「Guided Bug Form」というリンクを辿って表示される入力欄に報告の要約文を入力すると、似た要約の報告が列挙されるので、それらに倣ってComponentを選択しましょう。今回は、「Google Chromeの拡張機能APIと動作が異なっている」という観点で「Compatibility（互換性の問題）」を選択しました。
    • Version（バージョン）：現象の再現を確認できた最も新しいFirefoxのバージョンを選択します。今回はNightlyで再現を確認できているので、「Trunk」を選択しました17。
    • Type（種類）：「defect（壊れている、不具合）」「enhancement（機能改善の要望）」「task（プロジェクトのTODO）」から選択しますが、今回は不具合なので「defect」にしました。
  • Security（セキュリティ）：もしセキュリティ脆弱性の問題で、脆弱性の影響を受ける人がたくさんいそうな場合は、ここにチェックを入れます18。
  • Attachment（添付ファイル）：HTMLのテストケースや、スクリーンショットの画像、スクリーンキャストの動画など、不具合を説明する補助となるファイルを添付します。一度に添付できるファイルは1つだけなので、複数のファイルを添付したい場合は、一旦起票した後で、追加のコメントにファイルを添付する形にします。今回は「検証用に作ってみた、現象を再現させるための処理だけを含むアドオン」が既にあったので、そのxpiファイルを添付しました。
  • Description（説明）：報告の本文を書きます（Markdown可）。以下、本文の書き方のコツを詳述します。

BMOにはどのように不具合を報告するべきかが記載されたガイドライン（英語）があります。 大まかには前々項で説明した「報告内容の一般的な整理の仕方」と同様ですが、それに加えて、Mozillaプロジェクト固有の事情として、報告の種類ごとに重要な情報を含めるように書かれています。 具体的には以下の要領です。

  • Firefoxがクラッシュする不具合の場合、about:crashes で問題のクラッシュが起こったときのクラッシュレポートの「レポートID」またはURLを説明に含めます。クラッシュレポートはMozillaのサーバーに送信され解析されたものでないと第三者には見られないため、未送信のクラッシュレポートの場合は、「送信」ボタンで送信しておく必要があります。
  • メモリー使用量の異常な増大やメモリーリークの場合、about:memory で「Minimize memory usage」を実行した後で（それでもなおメモリー使用量が大きい状態で）「Measure and save」で保存した解析結果を添付します。
  • 動作速度の低下やCPU使用率の高止まりの問題の場合、プロファイラーを使って採取・送信した実行時プロファイルのURLを説明に含めます。
  • フリーズ（ハングアップ）する不具合の場合、報告する前に一般的な解消方法をまず試して、それでも依然として再現することを確認します。
  • 特定のWebページで起こる不具合の場合、可能な限り最小のテストケースを作って添付するようにします。テストケースを作れない場合は、Webページの互換性の問題のトラッキングサイトに報告することが推奨されます。
  • Nightlyで最近発生するようになった不具合や、以前のバージョンでは期待通りに動いていた機能がFirefoxの更新後に期待通りに動かなくなったという不具合の場合、いつの時点から不具合が起こるようになったかを調べて記載します。mozregressionというツールを使うと、「このバージョンでは問題が再現する」「このバージョンでは再現しない」ということを二分探索の要領で確認して、不具合が発生し始めたバージョンを絞り込むことができます。

今回は、拡張機能開発者向けのAPIの不具合という極めてハイコンテキストな話題のため、説明の重要な部分は実際のAPI呼び出しの例となるテストケースに担わせることにして、説明自体は簡素に以下のようにまとめました（実際の報告は英語で行っています）。

アンロードされたタブのIDを openerTabId に指定すると、browser.tabs.create() が意図せず例外を投げる。

元となった報告：https://github.com/piroor/treestyletab/issues/3099

再現手順：

  1. 2つ以上のタブを開く。
  2. そのうち1つをアンロードされた状態にする。
  3. browser.tabs.create({ openerTabId: <アンロードされたタブのID> }) を呼ぶ。

期待される結果： 新しいタブが成功裏に開かれる。

実際の結果： タブが開かれない。API呼び出しの例外を catch すると、「Error: An unexpected error occurred」というメッセージのエラーを得られる。

環境：

  • Windows 10 21H2
  • Nightly 100.0a1 build ID: 20220329204247
  • Firefox 98.0.2 build ID: 20220322144853

説明文の下にある「Request information from」欄は、報告内容に関係する他の人にメンションを飛ばすための物です。 一般の外部協力者として報告するときは、空欄のままで問題ありません。

最後に「Submit Bug」ボタンを押せば、起票は完了です。

報告した後にすること

起票が完了したら、報告者としてBugの行く末に関わり続けることになります。

  • 開発者が不具合を再現できなかったり、説明を上手く理解できなかった場合は、追加の情報提供を求められることがあります。そのときはコメントでさらなる情報提供に協力しましょう。
  • 同じ不具合がすでに別のBugで把握・管理されている場合、「Duplicate（重複）」として処理され、別のBugへ誘導された上でクローズされます。その場合は、誘導先のBugの内容を確認した上で、その後の行く末を見守りたい場合はページ上部の「Follow」ボタンを押して自分をそのBugの連絡先に追加したり、何か追加の情報を持っている場合はコメントで情報提供をしたりしましょう。
  • 活動歴が長くなってくると、「この問題は君が一番詳しそうだから、解決まで担当してくれ」ということで、自分がAssignに設定されることもあります。その場合は頑張って原因を調査して、パッチを提供することになります（無理そうなら、ギブアップを宣言して他の人に引き継いでもらいましょう）。

Bugの起票後は、開発者の判断によって「Priority（優先度）」と「Severity（重要度）」がそれぞれ設定されることがあります。 Priorityは「P1」から「P5」まであり、数字が小さいほど優先度が高いと判断されたことになり、Severityも「S1」のように数字が小さいほど重要度が高いということになります19。 ユーザーへの影響が大きい物ほどこれらが高く設定される傾向にあり、P1・S1ともなると、こちらが驚くほどの素早さで修正されることもあります。 P3やS3より数字が大きいと、外部からのコントリビューションがなければ修正されない可能性もあります。 ただ、これらの判断は流動的なため、コメントを通じての説得の仕方によっては優先度や重要度が後から変更されることも多々あります。 筆者が関わった事例では、遭遇した問題を報告しようとして既に他の人によって起票されたBugに辿り着き、そこに情報を提供した結果、実際に優先度や重要度が高く変更されてスピード解決に至った物もあります。

今回紹介した事例のBug 1762249はP3・S3となっていて、筆者の都合で解決までに3年を要してしまいましたが、筆者がパッチを提供して解決に至りました（この顛末の詳細は別記事でご紹介する予定です）。 報告したBugの優先度や重要度が低く判断された場合、ふて腐れたり拗ねたりしたくなる場合もあるとは思いますが、筆者としては、自分の手柄にする機会と捉えて解決に向けて主体的に関わってみることをお勧めしたいです。

まとめ

以上、Firefoxの不具合をMozillaプロジェクトに報告する手順を実際の事例を元にご紹介しました。

Firefoxは規模の大きなソフトウェアなので、毎日たくさんの不具合が発見され報告されています。 あなた自身がFirefoxを使っていて遭遇した不具合も、その中の1つに含まれている可能性がありますが、もしかしたらまだ誰も報告していないかもしれないし、たまたま条件が重なってあなたしか遭遇していないかもしれません。 心の内に仕舞ったり、SNSなどにボヤキを投稿して終わらせたりしてしまっては、そのまま不具合が見過ごされ続けてしまう恐れもあります。 皆さんも、未修正の不具合に遭遇することがあったら、是非とも開発元への報告に挑戦してみてください。

参考までに、他にも筆者が起票した報告をいくつかご紹介します。 「こんな風に報告するといいんだな」「こう書くといいんだな」といったことを把握するための参考にして頂ければ幸いです。

また、株式会社クリアコードは、FirefoxやThunderbirdの法人運用において生じた様々な問題について、ソースコードレベルの調査も含めたサポートを行うサービスを有償でご提供しています。 その結果未知の不具合であったことが分かれば、Mozillaへの報告も積極的に行っていて、以後のバージョンでの修正に繋がった事例も多数あります。 FirefoxやThunderbirdの運用で何かお困りの企業の運用担当者さまは、お問い合わせフォームよりお問い合わせ下さい。

  1. 「Bugzilla」はイシュートラッカーのソフトウェア自体の名称です。Bugzillaはそれ自体がオープンソースのソフトウェアで、独立したプロジェクトとして開発されており、Mozilla以外のプロジェクトでも採用されている事例があります。bugzilla.mozilla.orgは、Mozilla自身が運用しているBugzillaのインスタンスの一つということになります。 ↩

  2. 報告自体はかなり前に行ったのですが、最近解決された事例ということで採り上げています。 ↩

  3. 問題がNightlyで既に修正されているのであれば、順当にいけば最長でも8週間ほどで通常リリース版に修正が反映されることになるので、よほど深刻な不具合でないのなら気長に待てばよい、ということになります。ユーザーへの影響が甚大となる深刻な不具合の場合は、修正をベータ版や通常リリース版に急いで反映してもらうように交渉することになります。 ↩

  4. about:profiles を使うと普段使いのプロファイルとは別の新規プロファイルを使ってFirefoxを起動できます。新規プロファイルでは問題が再現しない場合、普段使いのプロファイルに含まれているアドオンや、何らかの設定値、履歴の内容などが再現性に影響している可能性があり、問題が再現するためにはどんな条件が必要なのかをさらに詳しく調べる必要があります。 ↩

  5. 報告時は、問題の再現を確認したFirefoxの正確なバージョンとビルドIDを添えるのが望ましいです。これらの情報は、about:support の情報をコピー＆ペーストすると間違いが無いです。 ↩

  6. FirefoxはオフィシャルにWindows版、macOS版、Linux版、Android版など各種OS用が存在しており、単にFirefoxと言っただけではどれのことなのか特定できません。また、特定のOSでしか再現しない問題の場合、開発者が異なるOSで検証して再現しないと、「再現性無し」として処理されてしまう恐れもあります。 ↩

  7. Firefoxでは、同じ機能をツールバーボタンから呼び出すかメニューから呼び出すかキーボードショートカットから呼び出すかで、微妙に動作結果が変わることがあります。操作の仕方が違うと問題を再現できないこともあるので、横着して「タブを開く」のようにざっくり書くのではなく、必ず「キーボードのCtrlキーを押しながらTキーを押してタブを開く」「タブバー内の＋ボタンをクリックしてタブを開く」のように、操作の仕方まで含めて書き出すようにしましょう。 ↩

  8. 例えばWindows 10やWindows 11であれば、Windows付属の「Snipping Tool」で画面内の一部分を切り取った動画を撮影できます。 ↩

  9. 一般的な「新機能の要望」はMozilla Connectというサービスで受け付けられています。そこで提案の具体性が高められた物は、個々の作業がBMOに起票され管理されることになります。 ↩

  10. 修正済みの問題なら検索結果に出てこない方が良いのでは、と思う所ですが、Firefoxの場合は不具合が修正されてから一般向けのリリースに反映されるまで8週間のタイムラグがあります。最新の開発版では既に修正済みでも一般向けのリリースではまだ直っていない、という不具合の場合に重複した報告を防ぐためには、解決済みの不具合も検索対象に含める必要があります。 ↩

  11. Googleで site:bugzilla.mozilla.org tabs.create discarded のようにサイト内検索する方法もありますが、すべての報告がインデックス化されているわけではないようで、この方法だと見落としが発生する可能性があります。BMOの検索は原則としてBMO自体の検索機能を使うようにするのがお勧めです。 ↩

  12. 「discarded」は、アンロードされたタブの内部的な状態をWebExtensions API上で表す際に使われるプロパティ名です。今回はWebExtensions APIに関する不具合であったため、検索キーワードもWebExtensions APIの用語を使いました。 ↩

  13. 実際に、タブの待機状態を表すフレーズとしてよく使われる「unloaded」や「suspended」など複数の表現を切り替えて検索してみましたが、それでも同じ問題の報告は見つかりませんでした。 ↩

  14. BMOはGravatorに対応しており、Gravatorの同じメールアドレスのアカウントでプロフィール画像を設定してあれば、人影のデフォルトアイコンの代わりに、自動的にGravatorの画像を参照して表示してくれます。 ↩

  15. 大前提となりますが、BMOでは報告はすべて英語で書く必要があります。自分で英作文するのが苦手な場合、ChatGPTなどのLLMベースの生成API相手に日本語の文章を「これを英訳して」と投げるなど、機械に翻訳を任せる方法もありますが、主語や目的語などを中途半端に省略した「こなれた日本語」を渡すと、見当違いの補い方をされた訳になる恐れもあります。機械に翻訳をさせる場合、元の日本語の表現もなるべく主語や目的語を明記した英訳文調の硬い表現にしたり、生成API相手であれば文脈を補う前提条件を同時に渡すなどして、見当違いの翻訳をされにくくすることをお勧めします。 ↩

  16. 「WebExtensions API」という部分はプロダクトの選択で既に示されているので、要約には含めませんでした。 ↩

  17. 「trunk」は、Mozillaプロジェクトのリポジトリーで開発のメインラインとなるブランチの伝統的な呼び方で、Git時代に一般的に言うmainやmasterに該当します。「Nightly」は、そこからビルドされたアプリの名称です。 ↩

  18. ここにチェックを入れた場合は、報告が一般には公開されない形で起票され、セキュリティ事案を閲覧できる権限がある人のチェックを受けることになります。 ↩

  19. BMOのユーザーガイドによると、PriorityはP1が現在のリリースサイクルで修正する問題、P2が次のリリースサイクル以降で修正する問題、P3がいわゆるTODOとしての記録に留める問題、P5が修正予定なしの問題（ただしパッチ提供は受け付ける）、P4がbotが使用する専用の値とされています。また、SeverityはS1が25％以上のユーザーに影響し回避策なしのため緊急リリースの必要がある問題、S2が目立つ機能の不具合で深刻かつ回避策なしの問題、S3がそれほど致命的でないか回避策がある問題、S4が影響度の低い些細な問題とされています。 ↩

関連情報

現在クリアコードではソフトウェア開発者を募集しています！ フリーソフトウェア開発での開発の仕方をベースに、成果や知識を公開し共有しながら業務に携われます。

クリアコードのYouTubeチャンネルです。メンバーの登壇動画や、開発プロダクトに関する動画を公開しています。

1年間の長期サポート版のあるメールクライアントThunderbirdは企業様向けに、一定の支持をいただいています。
クリアコードではカスタマイズなどのサポートをご案内しています。