ブラウザで見つかった問題をブラウザ ベンダーに伝えることは、ウェブ プラットフォームの改善に欠かせない要素です。
バグを報告する方法は適切ですが、手間がかかります。ブラウザ エンジニアが、問題の原因をできるだけ簡単に見つけ、根本原因を突き止め、最も重要なことに、問題を解決する方法を見つけられるようにすることが目標です。急速に進展するバグは、想定される動作が明確で、再現が容易な傾向があります。
バグであることを確認する
最初のステップは、「正しい」動作を特定することです。
正しい動作はどのようなものですか？
MDN で関連する API ドキュメントを確認するか、関連する仕様を探します。この情報は、実際に不具合のある API、不具合のある場所、想定される動作を判断するのに役立ちます。
別のブラウザで機能しますか？
ブラウザ間で動作が異なる場合は、通常、相互運用性の問題として優先度が高くなります。特に、バグを含むブラウザが異常な場合です。BrowserStack などのツールを使用して、Chrome、Firefox、Safari、Edge の最新バージョンでテストしてみてください。
可能であれば、ユーザー エージェント スニッフィングが原因でページが意図的に動作していないことを確認します。Chrome DevTools で、User-Agent 文字列を別のブラウザに設定してみてください。
最近のリリースで問題が発生しましたか？
以前は想定どおりに動作していたが、最近のブラウザ リリースで動作しなくなったか？このような回帰は、特に、正常に動作したバージョン番号と失敗したバージョン番号を指定すると、より迅速に対応できます。古いブラウザのバージョンは、BrowserStack などのツールを使用して確認できます。bisect-builds ツール（Chromium 用）などのツールを使用して変更を検索します。
問題が回帰であり、再現できる場合は、通常、根本原因を迅速に特定して修正できます。
他のユーザーにも同じ問題が発生していますか？
問題が発生している場合は、他のデベロッパーにも発生している可能性があります。まず、Stack Overflow でバグを検索してみてください。これは、抽象的な問題を特定の機能しない API に変換し、バグが修正されるまでの短期的な回避策を見つけるのに役立ちます。
以前に報告されたことがありますか？
バグが何であるかがわかったら、ブラウザのバグデータベースを検索して、そのバグがすでに報告されているかどうかを確認します。
- Chromium ベースのブラウザ: https://crbug.com
- Firefox: https://bugzilla.mozilla.org/
- Safari および WebKit ベースのブラウザ: https://bugs.webkit.org/
問題を表す既存のバグを見つけた場合は、そのバグにスターを付ける、お気に入りに追加、コメントするなどしてサポートしてください。また、多くのサイトでは、CC リストに自分自身を追加して、バグが変更されたときに最新情報を受け取ることができます。
バグについてコメントする場合は、バグがウェブサイトに与える影響に関する情報を含めてください。「+1」形式のコメントは追加しないでください。バグトラッカーは通常、コメントごとにメールを送信するためです。
バグを報告
以前にバグが報告されていない場合は、ブラウザ ベンダーに報告する必要があります。
最小化されたテストケースを作成する
Mozilla には、最小化されたテストケースを作成する方法に関する優れた記事があります。要するに、問題の説明は良いスタートですが、バグにリンクされたデモを添付して問題を示すのが最善です。迅速な解決を最大限に進めるには、問題を示すために必要な最小限のコードがサンプルに含まれている必要があります。バグの修正の可能性を高めるためにできることは、最小限のコードサンプルを提供することです。
テストケースを最小限に抑えるためのヒントをいくつかご紹介します。
- ウェブページをダウンロードし、
<base href="https://original.url">を追加して、ローカルにバグが存在することを確認します。URL が HTTPS を使用している場合は、ライブ HTTPS サーバーが必要な場合があります。 - できるだけ多くのブラウザの最新ビルドでローカル ファイルをテストします。
- すべてを 1 つのファイルにまとめるようにしてください。
- バグがなくなるまで、不要なものからコードを削除します。
- バージョン管理を使用して、作業を保存し、問題が発生した場合は元に戻すことができます。
圧縮されたテストケースをホストする
圧縮されたテストケースをホストするのに適した場所を探している場合は、いくつかの適切な場所があります。
これらのサイトの中には、コンテンツを iframe に表示するサイトがあるため、機能やバグの動作が異なる場合があります。
問題を報告する
テストケースを最小限に抑えたら、バグを報告する準備が整います。適切なバグ トラッキング サイトに移動して、新しい問題を作成します。
- Chromium ベースのブラウザ - https://crbug.com/new
- Firefox - https://bugzilla.mozilla.org/
- Safari と WebKit ベースのブラウザ - https://bugs.webkit.org/
明確な説明と複製の手順を追加する
まず、エンジニアが問題をすばやく把握し、問題の優先順位付けができるように、わかりやすい説明を入力します。
When installing a PWA using the `beforeinstallprompt.prompt()`, the
`appinstalled` event fires before the call to `prompt()` resolves.
次に、問題を再現するために必要な詳細な手順を提供します。 ここで、圧縮されたテストケースの出番です。
What steps will reproduce the problem?
1. Go to https://basic-pwa.glitch.me/, open DevTools and look at the
console tab.
2. Click the Install button in the page, you might need to interact with
the page a bit before it becomes enabled.
3. Click Install on the browser modal install confirmation.
最後に、想定される結果と実際の結果を説明します。
What is the expected result? In the console:
0. INSTALL: Available (logged when `beforeinstallprompt` event fired)
1. INSTALL_PROMPT_RESPONSE: {outcome: "accepted", platform: "web"}
(logged when beforeinstallprompt.prompt()` resolves)
2. INSTALL: Success (logged when `appinstalled` event fired)
What is the actual result? In the console:
0. INSTALL: Available (logged when `beforeinstallprompt` event fired)
1. INSTALL: Success (logged when `appinstalled` event fired)
2. INSTALL_PROMPT_RESPONSE: {outcome: "accepted", platform: "web"}
(logged when beforeinstallprompt.prompt()` resolves)
詳しくは、MDN のバグレポートの作成ガイドラインをご覧ください。
参考: 問題のスクリーンショットまたはスクリーンキャストを追加する
必須ではありませんが、問題のスクリーンショットやスクリーンキャストを追加すると、問題の解決に役立つことがあります。これは、複数のステップや異常なアクティビティの後にバグが発生した場合に特に役立ちます。スクリーンキャストやスクリーンショットを使用すると、ブラウザ エンジニアに問題をよりわかりやすく説明できます。
環境の詳細を含める
一部のバグは、特定のオペレーティング システムでのみ、または特定の種類のディスプレイ（低 DPI や高 DPI など）でのみ再現できます。使用したテスト環境の詳細を必ず含めてください。
バグを送信する
最後に、バグを送信します。バグへの返信が届くようメールをご確認ください。 通常、調査中にエンジニアから追加の質問を受けることがあります。問題の再現が難しい場合は、問い合わせがあることもあります。