ブラウザで見つけた問題をブラウザ ベンダーに伝えることは、ウェブ プラットフォームの改善に欠かせません。
バグの報告は難しくありませんが、少々手間がかかります。目標は、破損している箇所を簡単に見つけて根本原因を特定し、最も重要な点として、修正方法を見つけることです。バグの進行が速く、明確な想定動作で容易に再現できる傾向があります。
バグであることを確認する
最初のステップは、「正しい」動作とは何かを見つけることです。
正しい動作はどれですか。
MDN で関連する API ドキュメントを確認するか、関連する仕様を見つけてください。この情報は、実際に破損している API、破損している場所、想定される動作を判断するのに役立ちます。
別のブラウザで機能しますか?
一般に、ブラウザによって異なる動作は相互運用性の問題として優先順位が高くなります。特に、バグを含むブラウザが奇妙な場合はなおさらです。Chrome、Firefox、Safari、Edge の最新バージョンで、おそらく BrowserStack などのツールを使用してテストしてみてください。
可能であれば、ユーザー エージェント スニッフィングが原因でページが意図的に動作していないことを確認します。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 など)でのみ再現できます。使用したテスト環境の詳細も必ず記載してください。
バグを送信する
最後に、バグを報告します。その後、バグに対する返信メールをチェックします。通常、調査中やバグの修正時にエンジニアは追加の質問をすることがあります。また、問題の再現が難しい場合は、問い合わせを行うこともあります。