Bugs in Thunderbird are tracked using the Bugzilla database. With the increasing popularity of Thunderbird, lots of bad bug reports are being filed and many of the good ones are duplicates of already filed bugs. The purpose of this page is to help you file better bug reports, which in the end will help the developers fixing the bug.
Before filing a bug report
There are four crucial steps that you should follow before filing your first bug report:
- Use the latest nightly build of Thunderbird with a new profile
- Determine which product has the bug
- Check if the bug is already filed
- Finally, read the official Bug Writing Guidelines
1. Use the latest version of Thunderbird with a new profile
Make sure you are using the latest nightly build of Thunderbird. Always install it in an empty folder.
Create a new Thunderbird profile and then start Thunderbird using that profile. Now, try to reproduce the bug. Of course, if what you're about to file is not a bug, but an enhancement request (RFE), you can skip this step. If you do not see the bug when using the latest nightly build and a new profile, there are two possibilities: either the bug is fixed in the latest builds, or seeing the bug depends on something in the profile you normally use.
To determine which of these is the case, try testing the bug using a new profile, but with the same build in which you were seeing the bug. If you do see the bug in this situation, then it's been fixed in the latest builds, and there's no need to file a bug report.
However, if you do not see the bug in this situation, then seeing the bug depends on something that is in the profile you normally use. This means it is a bug, but the information in the bug report needs to include information on how to turn a clean profile into a profile where the bug can be seen. Figuring out what in your existing profile triggers the bug may require some guesswork. It could be a preference, an extension you have installed, something in a database like address books, message folders, or saved passwords, or something else. You can determine this by doing things like installing in the clean profile extensions that you have in your normal profile, temporarily disabling extensions in your normal file, copying files (like prefs.js or localstore.rdf) from your normal profile to the clean profile, or other methods. Once you figure this out, remember to include in the bug report the simplest way to turn a clean profile into a profile where the bug can be seen.
2. Determine which product has the bug
Thunderbird is built on the Mozilla toolkit; so many bugs in Thunderbird may not be specific to Thunderbird, but actually bugs in the Mozilla toolkit, or even the core Mozilla code. The major difference between Thunderbird and Mozilla is the user interface (e.g. the toolbars, menus, status bar, etc., referred to as the "chrome" in Mozilla terms). That means, if you're experiencing a problem with the toolbar, it's probably a Thunderbird bug. If you're having problems with functionality, it is most likely a Mozilla core bug. If you're still unsure of which product your bug belongs under, browse though the component list of Thunderbird, Toolkit, and Core, to find which product contains the component most appropriate for your bug report.
Optionally, you can download the latest SeaMonkey nightly and try to reproduce the bug using a clean SeaMonkey profile. If the bug exists in SeaMonkey, you should file the bug in the most relevant component of the product Core.
3. Check if the bug is already filed
The list of previously filed bugs is constantly growing, but if you look in the appropriate category, you'll notice that the list isn't that long. The components in Thunderbird are:
- Account Manager
- Address Book
- Build Config
- Help Documentation
- Mail Window Front End
- Message Compose Window
The links above display a list of all bugs for that component (except the duplicates). If this is a new bug in the latest nightly build, you could always look in the list of bugs filed today. For the complete list of Thunderbird bugs, including duplicates, click here (will take a while to load).
4. Finally, read the official Bug Writing Guidelines
This last step only needs to be done once (hopefully), and is probably the most important one. You should never file a bug report before reading the official Bug Writing Guidelines, written by Gervase Markham. You will learn how to write a detailed and useful bug report, which will reduce the time it takes for a developer to fix the bug.
Filing a bug report
If you've followed the steps above, you are ready to file the bug report. Follow the instructions on the page. Since you've already searched for previously filed bugs, you can skip Step 1 - search for your bug.© 2002-2005 David Tenser.