ブラウザで見つかった問題をブラウザ ベンダーに伝えることは、ウェブ プラットフォームの改善に欠かせない要素です。
バグを報告するのは良い方法ですが、少し手間がかかります。ブラウザ エンジニアが、問題の原因をできるだけ簡単に見つけ、根本原因を突き止め、最も重要なことに、問題を解決する方法を見つけられるようにすることが目標です。急速に進展するバグは、想定される動作が明確で、再現が容易な傾向があります。
バグであることを確認する
最初のステップは、「正しい」動作を特定することです。
正しい動作はどのようなものですか?
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 など)でのみ再現できます。使用したテスト環境の詳細を必ず含めてください。
バグを送信する
最後に、バグを送信します。バグへの返信が届くようメールをご確認ください。 通常、調査中にエンジニアから追加の質問を受けることがあります。問題を再現できない場合は、お客様からお問い合わせを受けることがあります。