Webブラウザーの改善を支援する

次のデザインを静かに作り上げていますが、今回はCSS3とHTML5を試してみることにしました。これらの新しい仕様は、ほとんどの最新ブラウザーで完全にサポートされているからです。 新しいテクノロジーが作業を簡素化する方法を時々考えて、かなりの量のコードをすでに構築しているのに、しばらく停止して他のブラウザーでページの動作を確認することが突然起こりました。 ヤギは理解できるので、あなたはすでに緊張し始めています-同様のチェックをはるかに早い段階で実行する必要がありました。 所有しているすべてのブラウザーを起動し、コンピューターに「作業をお願いします」とささやきます。 ブラウザA、すべてが機能します。 あなたは笑顔で、安心します。 ブラウザBとすべてが正常です。 あなたは微笑んで、あなたの気分は上がります。 ブラウザC ...「FUUUUUUUUUUUUUUUUUU！」





驚くかもしれませんが、この状況は常にWeb開発者のせいではありません。 Webブラウザー市場での現在の軍拡競争とWebテクノロジーと仕様の驚くべき進歩の中で、ブラウザーのメーカーは、適切なテストを行わなくても、時々新しい機能を急いで導入しています。 CSS3とHTML5は以前のバージョンよりもはるかに複雑であり、新機能の可能な組み合わせの数はオフスケールであり、これは多くの場合バグの原因です。2つ（またはそれ以上）の部分は一緒にテストされません。 その結果、ブラウザー開発者は、バグの修正に必要以上の時間を費やしています。

なぜバグを開発者に報告する必要があるのですか？

そうしないと、だれも気付かない可能性があります。 おそらくあなたが見つけたバグは非常にまれであるため、他の誰もそのバグに遭遇することはありません。 またはつまずくが、それを開発者に報告する方法を知らないか、まったくブラウザではないと考えるでしょう。 さらに、バグが発生するような方法でコードに新しいテクノロジーを使用した場合、同じ方法で再び偶然に遭遇する可能性が高いため、迅速な修正もあなたの利益になります。 そして、最終的には、他の何千人ものWeb開発者があなたが経験した厄介な問題を回避するのを助けることができます。



バグを報告するのは無意味だと思うかもしれません。バグを修正するには何年もかかり、ユーザーがブラウザーの修正バージョンにアップグレードするのにさらに時間がかかるからです。 秘密をお伝えします。IEを除くすべてのブラウザーでは、すべてがはるかに優れています。 最近では、Firefox、Opera、Safari、Chromeのユーザーは、ブラウザ開発者のおかげで大部分が新しいバージョンに非常にすばやく更新されます-更新を提供する迷惑なウィンドウ、新しいバージョンのプロパガンド、ユーザーの知らない間に完全に自動化されたサイレント更新（Chromeについて話している） ） バグ、特に開発者に正式に報告されたバグは非常に迅速に修正されます。

バグの原因を見つける

適切なレポートを作成するための最初のステップは、問題の原因を見つけることです。 言い換えれば、不必要なゴミで開発者を煩わさないために、問題のあるコードを最小化する必要があります。 バグがページのレンダリングに関係する場合、問題を引き起こすコードをレポートに添付する必要があります。 そして、あなたが間違いを犯し、問題がブラウザにない場合でも、少なくともあなたはそれについて知っているでしょう、そして経験は決して不必要ではありません。



コードを最小限に抑えるアルゴリズムを次に示します。

1. バグを発見したフォームのどこかにプロジェクトをコピーします。
2. コードを開き、ページで使用されているCSSファイルとJSファイルのコンテンツを徐々に削除し始めます。 最後に、次のアンインストール後に、バグが消えたことがわかります。 この場合、削除されたコードフラグメントを返し、バグが残るように他のすべてを削除しようとします。 まれに、CSSとJSを削除しても意味がない場合があります。これは、HTMLに問題がある可能性が高いことを意味します。
3. 次に、バグの原因となっている特定のコードブロックを見つける必要があります。 問題がなくなるまで、コメント内のコードをゆっくりと注意深く囲みます。 個人的には、バイナリメソッドを使用してこれを行う方がはるかに簡単です。最初に、コードの約半分をコメントアウトします。 バグが残っている場合は、コメントアウトされたコードを削除し、残りのコードの半分をコメントアウトして、手順を繰り返します。 残念ながら、余分なガベージからコードを削除するのは遅れる可能性があります。特定のコードを特定の方法で組み合わせた場合にのみバグが発生する状況がありました。
4. style
   
   
   
   またはscript
   
   
   
   でラップすることにより、残りのCSSおよびJSコードをファイルからHTMLページに転送しscript
   
   
   
   。 これにより、レポートがより正確になります。
5. 次に、不要なHTMLを削除します。 まず、識別情報や個人情報をすべて削除してから、他のすべてを削除します。 たとえば、バグがCSSの動作に関連している場合、バグの原因となっているスタイルに適用されていないすべての要素を削除します。
6. title
   
   
   
   の内容をバグに関連するものに変更します。

これで、このエラーまたはそのエラーの原因となる、きれいで読みやすいコードができましたが、まず確認する必要があります。 有効ですか？ ブラウザ開発者は、Webコーダーのエラーを考慮に入れず、製品に通常エラーコードを処理させることはできません。 または、オンライン検証ツールを使用します。



時間に余裕があり、バグレポートを理想的な外観にしたい場合は、次のことを行う必要があります。

1. バグの範囲を確認できるように、コードに小さな変更を加えてみてください。 たとえば、ブラウザがborder-radius: 50%
   
   
   
   正しく処理しないことがわかった場合、異なる値（たとえば40％）でバグが表示されるかどうかを確認します。 バグが表示されない場合でも、開発者が実験を繰り返す必要がないように、レポートに実験を記載することをお勧めします。
2. 実際には何も変更しないコードを変更してください。たとえば、すべての値をem
   
   
   
   からpx
   
   
   
   変換します。 繰り返しますが、結果に関係なく、レポートで行われた作業に言及してください。

持っているコードを処理する時間がない場合でも、バグレポートを作成します。 悪いレポートは何もないよりはましです。 この場合、開発者はコードの処理を行いますが、他のバグレポートが多数あるのと同じことを覚えているため、レポートの公開からエラーの修正までに時間がかかります。

バグを報告する必要がありますか？

レポートを公開しない主な理由はいくつかあります。

• 実際、バグと間違えたのはバグではありません。
• このバグは、最新の夜間バージョンですでに修正されています。
• このバグは他の誰かによってすでに報告されています。

3つの理由すべてのために歩きます。

バグかどうか

ほとんどの場合、コードをゴミから削除し、バグの原因のみを残した場合、観察されたエラーがブラウザ開発者の作業の結果であるかどうかを非常に簡単に判断できます



どういうわけか私はoutline-color: invert



がすべてのブラウザーで機能しないことを発見しました。 正確には、Firefox、Safari、Chromeについてでした。 リストされているブラウザーはこのコードを無視しませんでしたが、 currentColor



を使用しているかのように処理しました。 もちろん、コードをクリーンアップしてエラーを特定し、リストされているすべてのブラウザーのバグトラッカーに関するレポートを作成しました。 しばらくして、ブラウザの開発者にはこの方法でこのパラメーターを処理する権利があるという仕様に脚注があり、バグのような匂いがないことがわかりました。 教訓は、レポートを公開する前に、タグ付けされたと思われるパラメーターの仕様を注意深く読む必要があるということです。 さらに、そのような機能を認識することで、開発者として貴重な経験を積むことができます。



別のケースがありました。CSS3仕様に目を通し、境界線がどのように機能するかの説明に出会いました。 もちろん、私の手はくすんでいたので、この機能をテストすることにしましたが、最新の単一のブラウザーでは、読んだ仕様に従ってコードをレンダリングしませんでした。 バグレポートを設計して公開しましたが、このレポートには、この機能が仕様の最新の開発バージョン（つまり、未公開）から削除されたという回答がありました。 この話の教訓は簡単です。バグを仕様と比較すると、公開されているものの代わりにdevバージョンを読みます。



もちろん、すべての人々と同様に、ウェブ開発者は愚かであることが起こります。 そして、バグはバグではなく、不完全な仕様やコードのエラーではなく、単に不注意によるものであることがわかりました。 エラーが発生していなくても、1つのJSコードを動作させることができなかったときの不満を覚えています。 結局、最近ブラウザでJavaScriptをオフにして、再びオンにするのを忘れていたことがわかりました。



私の練習の中で最も屈辱的なケースを覚えています。 バグレポートを作成し、Operaのバグトラッカーに公開しました。これは、 pointer-events



が機能せず、 select



に囲まれている状況を説明したものです。



まれに、バグは実際にはバグですが、特定のブラウザとは関係ありません。 マークアップ言語の仕様にもエラーが含まれる場合があります。 このようなバグは、1つまたは別の仕様の開発者のWebサイトに報告する必要があります（CSSの場合、 W3Cバグトラッカーが必要です）。 そのようなエキゾチックな場合でも、上記の指示はまだ適用可能です。

最新のNightlyビルドでバグは修正されましたか？

ブラウザの「夜」バージョンがまだない場合は、これを行う必要があります。 最も人気のあるブラウザの最新の（潜在的に不安定な）ビルドのリストは次のとおりです。

• IE 10プラットフォームプレビュー2
• Firefoxナイトリー
• オペラネクスト
• クロムカナリア
• Webkitナイトリービルド

明らかに、バグがブラウザの最新の夜間バージョンに表示されない場合、バグレポートを行うべきではありません。 安定版リリースブランチで修正されるまで待ってください。 言い換えれば、必要なのは忍耐力、若いパダワンだけです。

同様のバグレポートはすでに作成されていますか？

仕様を注意深く読み直し、ナイトビルドをインストールした後でもバグがあると確信している場合は、バグトラッカーを調べて問題を説明するバグレポートを作成する必要があります。 バグトラッカーの検索エンジンが、未確認および修正済みのバグを含むすべての結果を提供することを確認してください。



レポートが見つからない場合は、同義語を使用して検索クエリを変更し、探しているレポートの可能な名前をすべて考えてみてください。



レポートであなたの前に誰かを見つけましたか？ 急いで離れないでください。一部のバグトラッカー（Bugzillaなど）は投票をサポートしています。 開発者がバグレポートの評価を考慮するかどうかはわかりませんが、そうであれば、高い評価は発見されたエラーのより早い除去に貢献します。

異なるエンジン、異なるバグトラッカー

各ブラウザーには、ユーザーが発見したエラーを公開するために設計された独自のバグトラッカーがあります。

• インターネットエクスプローラー
• Firefox
• Operaウィザード
• Webkit
• クロム

SafariとChromeは同じWebkitエンジンに基づいているため、両方のブラウザーにバグが表示される場合は、Webkitバグトラッカーに書き込む必要があります。



1つを除いて、すべてのバグトラッカーは公開されています：Opera Wizard。 バグレポートをOperaに送信できますが、他のユーザーが送信したレポート、ユーザーのディスカッション、修正の進行状況にアクセスすることはできません。 これらすべてへのアクセスは、Operaのボランティアと従業員のみが利用できます。 招待状によってのみ（非公開契約の締結により）ボランティアになることができ、大切な招待状を取得することは簡単な作業ではありません。 あなたが見つけたすべてのエラーを送れば、おそらくあなたは幸運になるでしょう。

良いバグレポートを作成する

適切なレポートの最も重要な部分は、不要なゴミからクリーンアップされたコードです。 これが最も難しい部分であり、残りは5分以内に完了します。

短い説明

簡単な説明は、レポートの2番目に重要なものです。 完璧なバランスを見つける必要があります。バグの簡単な説明は長すぎたり短すぎたりしてはいけません。 これが良い例です：

body{display:table}



を使用すると背景画像が消えbody{display:table}



（Firefoxでの正しいセンタリング+スクロールのための一般的なCSSハック）

さらに、短い説明にタグを追加して、他のユーザーがレポートをすばやく簡単に見つけられるようにすることができます。 たとえば、最後に、オペレーティングシステム、タグ付きパラメーター、および原則としてあなたの心が望むものを割り当てることができます。主なことは、タグがバグに直接関連していることです。

基本情報

ここでは、原則として、すべてが非常に単純です。 クリーンなコードへのリンクを提供し、実験結果をバグと共有し、エラーの考えられる原因について個人的な意見をお聞かせください。 主なことは、おしゃべりを減らし、仕事を増やすことです。 バグを選ぶ前に鼻をつまんでいたという事実について話す必要はありません。 エラーの調査に役立たない情報は避けてください。

すべきでないこと

決して、いくつかの異なるバグに関する情報を1つのレポートに決して表示しないでください。 これにより、今回の問題の解決に混乱と追加の障害が生じます。



2つ目は、一部のエラーがワークフローを悩ませたり、妨害したり、遅くしたりする可能性があることを理解できますが、無礼は役に立ちません。 特にレポートの議論では落ち着いて、「これらのバカがどんなバグについて話すことができるか信じられない！」

次は？

通常、数日または数週間のうちに、誰かがレポートのステータスを変更します。 このレポートが二重であると言われた場合、心配しないでください、これは誰にでも起こります。 レポートのステータスが「確認済み」になっている場合、これは本当に新しいバグを見つけたという良い兆候です。 時間が経つにつれて、ステータスは「送信済み」に変わります。これは、レポートがブラウザ開発者に直接送信されたことを意味し、おそらくすぐにこのエラーを修正します。 レポートが「固定」カテゴリで特定された場合-おめでとうございます。ブラウザの開発に貢献しました。

---

元の記事： ヘルプコミュニティ：レポートブラウザーのバグ

投稿者： Lea Verou

発行日：09/07/11

---

このテキストは、 Creative Commons Attribution-NonCommercial-ShareAlike 3.0ライセンスの下でライセンスされています。

オリジナルのライセンスの作成と保存を義務付けて、このテキストを非営利目的でコピー、編集、使用できます。