Bug writing guidelines

  • Revision slug: Bug_writing_guidelines
  • Revision title: Bug writing guidelines
  • Revision id: 12925
  • Created:
  • Creator: Jesse
  • Is current revision? No
  • Comment 119 words added, 275 words removed

Revision Content

If you need help with Mozilla software (for example with Firefox or Thunderbird), use one of the available support options. Do not edit this page.

If you're new to reporting bugs, you may want to try getting help from the more experienced contributors. See the Community section on the QA page for pointers. If you're going to report a Firefox bug, you can also get assistance in the #firefox channel on irc.mozilla.org.

Principles

Effective bug reports are the most likely to be fixed. These guidelines explain how to write such reports.

  • Be precise
  • Be clear - explain it so others can reproduce the bug
  • One bug per report
  • No bug is too trivial to report - small bugs may hide big bugs
  • Clearly separate fact from speculation

Preliminaries

  1. Reproduce your bug using a recent build of the software, to see whether it has already been fixed.
  2. Search Bugzilla to see whether your bug has already been reported (tutorial).

Reporting a New Bug

If you have reproduced the bug in a recent build and no-one else appears to have reported it, then:

  1. Choose "Enter a new bug" (that form incorporates parts of these guidelines)
  2. Select the product in which you've found the bug
  3. Fill out the form. Here is some help understanding it:

Component: In which sub-part of the software does it exist?

This field is required. Click the word "Component" to see a description of each component. If none seems appropriate, look for a "General" component.

OS: On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.)

If you know the bug happens on more than one type of operating system, choose "All." If your OS isn't listed, choose Other.

Summary: How would you describe the bug, in approximately 60 or fewer characters?

A good summary should quickly and uniquely identify a bug report. It should explain the problem, not your suggested solution.

  • Good: "Cancelling a File Copy dialog crashes File Manager"
  • Bad: "Software crashes"
  • Bad: "Browser should work with my web site"

Description: The details of your problem report, including:

Overview: More detailed restatement of summary.

Drag-selecting any page crashes Mac builds in the NSGetFactory function.

Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps.

1) View any web page. (I used the default sample page, 
resource:/res/samples/test0.html)

2) Drag-select the page. (Specifically, while holding down 
the mouse button, drag the mouse pointer downwards from any 
point in the browser's content region to the bottom of the 
browser's content region.)

Actual Results: What the application did after performing the above steps.

The application crashed.

Expected Results: What the application should have done, were the bug not present.

The window should scroll downwards. Scrolled content should be selected. 
(Or, at least, the application should not crash.)

Build Date & Platform: Date and platform of the build in which you first encountered the bug.

Build 2006-08-10 on Mac OS 10.4.3

Additional Builds and Platforms: Whether or not the bug takes place on other platforms (or browsers, if applicable).

Doesn't Occur On Build 2006-08-10 on Windows XP Home (Service Pack 2)

Additional Information: Any other useful information.

Add an attachment: You can attach relevant files to a bug report. Debugging information more than 20 lines long should be supplied this way. Also, if you have an HTML file that demonstrates the bug, you should attach that. You can only attach one file during initial submission so if your demonstration needs more, revisit the newly filed bug to do this part. Attach any subsidiary files (such as images) first and then edit the HTML file to point to the new URLs of the attached files before uploading, so the demo is self-contained. Ask before attaching more than five files.

Double-check your report for errors and omissions, then press "Commit." Your bug report will now be in the Bugzilla database.

Specific types of bugs

If you are reporting a crash bug, please include a Breakpad ID or attach stack trace, and include the crash signature in the bug summary.

If you are reporting a leak bug, please attach the output of about:memory (Firefox 6+). Ideally, find steps to reproduce an increase in what is shown in about:memory (even after clicking the "Minimize memory usage" button at the bottom). If you have trouble finding steps to reproduce, try the Firefox Support page titled High Memory Usage. If you are a C++ developer, more precise tools are available.

Original document information

  • Author(s): Gervase Markham, based on an original by Eli Goldberg
  • Other Contributors: Claudius Gayle, Jan Leger, Felix Miata, Peter Mock, Chris Pratt, Chris Yeh, Jesse Ruderman, and others.

{{ languages( { "de": "de/Richtlinien_zum_Schreiben_eines_Bugreports", "fr": "fr/Recommandations_pour_l\'\u00e9criture_d\'un_bug", "ja": "ja/Bug_writing_guidelines" } ) }}

Revision Source

<div class="note">
<p><strong>If you need help with Mozilla software (for example with Firefox or Thunderbird), use one of the available <a class="external" href="http://www.mozilla.org/support/">support options</a>. Do not edit this page.</strong></p>
<p>If you're new to reporting bugs, you may want to try getting help from the more experienced contributors. See the Community section on the <a href="/en/QA" title="en/QA">QA</a> page for pointers. If you're going to report a Firefox bug, you can also get assistance in the <span style="font-family: monospace;">#firefox </span>channel on <a class="external" href="http://irc.mozilla.org/" title="http://irc.mozilla.org/">irc.mozilla.org</a>.</p>
</div>
<h2>Principles</h2>
<p>Effective bug reports are the most likely to be fixed. These guidelines explain how to write such reports.</p>
<ul> <li>Be precise</li> <li>Be clear - explain it so others can reproduce the bug</li> <li>One bug per report</li> <li>No bug is too trivial to report - small bugs may hide big bugs</li> <li>Clearly separate fact from speculation</li>
</ul>
<h2>Preliminaries</h2>
<ol> <li>Reproduce your bug using a <a class="external" href="http://www.mozilla.org/developer/#builds">recent build</a> of the software, to see whether it has already been fixed.</li> <li>Search <a class="link-https" href="https://bugzilla.mozilla.org/">Bugzilla</a> to see whether your bug has already been reported (<a class="external" href="http://www.mozilla.org/quality/help/screening-duplicates.html">tutorial</a>).</li>
</ol>
<h2>Reporting a New Bug</h2>
<p>If you have reproduced the bug in a recent build and no-one else appears to have reported it, then:</p>
<ol> <li>Choose "<a class="link-https" href="https://bugzilla.mozilla.org/enter_bug.cgi?format=guided">Enter a new bug</a>" (that form incorporates parts of these guidelines)</li> <li>Select the product in which you've found the bug</li> <li>Fill out the form. Here is some help understanding it:</li>
</ol>
<p><strong>Component:</strong> In which sub-part of the software does it exist?</p>
<p>This field is required. Click the word "Component" to see a description of each component. If none seems appropriate, look for a "General" component.</p>
<p><strong>OS:</strong> On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.)</p>
<p>If you know the bug happens on more than one type of operating system, choose "All." If your OS isn't listed, choose Other.</p>
<p><strong>Summary:</strong> How would you describe the bug, in approximately 60 or fewer characters?</p>
<p>A good summary should quickly and uniquely identify a bug report. It should explain the problem, not your suggested solution.</p>
<ul> <li>Good: "Cancelling a File Copy dialog crashes File Manager"</li> <li>Bad: "Software crashes"</li> <li>Bad: "Browser should work with my web site"</li>
</ul>
<p><strong>Description:</strong> The details of your problem report, including:</p>
<div class="highlight">
<p><strong>Overview:</strong> More detailed restatement of summary.</p>
<pre class="eval">Drag-selecting any page crashes Mac builds in the NSGetFactory function.
</pre>
<p><strong>Steps to Reproduce:</strong> Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps.</p>
<pre class="eval">1) View any web page. (I used the default sample page, 
resource:/res/samples/test0.html)

2) Drag-select the page. (Specifically, while holding down 
the mouse button, drag the mouse pointer downwards from any 
point in the browser's content region to the bottom of the 
browser's content region.)
</pre>
<p><strong>Actual Results:</strong> What the application did after performing the above steps.</p>
<pre class="eval">The application crashed.
</pre>
<p><strong>Expected Results:</strong> What the application should have done, were the bug not present.</p>
<pre class="eval">The window should scroll downwards. Scrolled content should be selected. 
(Or, at least, the application should not crash.)
</pre>
<p><strong>Build Date &amp; Platform:</strong> Date and platform of the build in which you first encountered the bug.</p>
<pre class="eval">Build 2006-08-10 on Mac OS 10.4.3
</pre>
<p><strong>Additional Builds and Platforms:</strong> Whether or not the bug takes place on other platforms (or browsers, if applicable).</p>
<pre class="eval">Doesn't Occur On Build 2006-08-10 on Windows XP Home (Service Pack 2)
</pre>
<p><strong>Additional Information:</strong> Any other useful information.</p>
<strong>Add an attachment:</strong> You can attach relevant files to a bug report. Debugging information more than 20 lines long should be supplied this way. Also, if you have an HTML file that demonstrates the bug, you should attach that. You can only attach one file during initial submission so if your demonstration needs more, revisit the newly filed bug to do this part. Attach any subsidiary files (such as images) first and then edit the HTML file to point to the new URLs of the attached files before uploading, so the demo is self-contained. Ask before attaching more than five files.</div>
<p>Double-check your report for errors and omissions, then press "Commit." Your bug report will now be in the Bugzilla database.</p>
<h2>Specific types of bugs</h2>
<p>If you are reporting a <strong>crash bug</strong>, please <a href="/En/How_to_get_a_stacktrace_for_a_bug_report" title="https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report">include a Breakpad ID or attach stack trace</a>, and include the crash signature in the bug summary.</p>
<p>If you are reporting a <strong>leak bug</strong>, please attach the output of about:memory (Firefox 6+). Ideally, find steps to reproduce an increase in what is shown in about:memory (even after clicking the "Minimize memory usage" button at the bottom). If you have trouble finding steps to reproduce, try the Firefox Support page titled <a class=" external" href="http://support.mozilla.com/en-US/kb/High%20memory%20usage" title="http://support.mozilla.com/en-US/kb/High memory usage">High Memory Usage</a>. If you are a C++ developer, <a class=" link-https" href="https://wiki.mozilla.org/Performance:Leak_Tools" title="https://wiki.mozilla.org/Performance:Leak_Tools">more precise tools are available</a>.</p>
<div class="originaldocinfo">
<h2>Original document information</h2>
<ul> <li>Author(s): Gervase Markham, based on an original by Eli Goldberg</li> <li>Other Contributors: Claudius Gayle, Jan Leger, Felix Miata, Peter Mock, Chris Pratt, Chris Yeh, Jesse Ruderman, and others.</li>
</ul>
</div>
<p>{{ languages( { "de": "de/Richtlinien_zum_Schreiben_eines_Bugreports", "fr": "fr/Recommandations_pour_l\'\u00e9criture_d\'un_bug", "ja": "ja/Bug_writing_guidelines" } ) }}</p>
Revert to this revision