ブラウザで見つかった問題をブラウザ ベンダーに伝えることは、ウェブ プラットフォームを改善するうえで不可欠です。
適切なバグの報告は難しくないものの、少し労力がかかります。目標は、破損した箇所を簡単に見つけて根本原因を突き止め、そして最も重要なこととその修正方法を見つけることです。進行が早いバグは、明確な想定動作で再現しやすい傾向があります。
バグであることを確認する
最初のステップは、「正しい」動作を把握することです。
正しい動作はどれですか?
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 など)でのみ再現されます。使用したテスト環境の詳細を必ず含めてください。
バグを送信する
最後に、バグを送信します。また、バグに対する返答をメールで必ず確認するようにしてください。通常、エンジニアは調査とバグ修正の際に追加の質問をすることがあります。また、問題の再現が困難なエンジニアから問い合わせを受けることもあります。