Do you want to report a bug with one of our milestone or nightly builds or with a copy of Mozilla that you compiled yourself? Bugzilla is the place to submit bug reports for software distributed by mozilla.org. This page gives an overview of how Bugzilla works. Read the bug writing guidelines as well, for tips on how to write useful bug reports.
What Is Bugzilla?
Bugzilla is a database for bugs. It lets people report bugs and assigns these bugs to the appropriate developers. Developers can use Bugzilla to keep a to-do list as well as to prioritize, schedule and track dependencies.
Not all 'bugs' are bugs. Some items in the database are known as Enhancement Requests or Requests For Enhancement (RFE). An RFE is a bug whose severity field is set to 'enhancement'. People often say 'bug' when they mean 'item in Bugzilla', so RFEs often wind up being called bugs.
Enter the tasks you're planning to work on as enhancement requests and Bugzilla will help you track them and allow others to see what you plan to work on. If people can see your flight plan, they can avoid duplicating your work and can possibly help out or offer feedback.
Looking for the source of Bugzilla? If you want to set up a Bugzilla on your own server, you can get it here.
Anatomy Of A Bug
Bugs and RFEs are composed of many fields. Some of them are described here.
- Status Whiteboard
- The Status Whiteboard is used for writing short notes about the bug.
- This field is used to store various
Developers can use this field for posting
helpwantedin the Keywords field of one of your bugs or RFEs and others searching for things to do will find it. People interested in getting involved can search Bugzilla for bugs and RFEs marked
helpwanted. Maybe one of them will have the expertise and resources to help you with your problem.
For instance, if your code has a bug on some platform which you don't have access to, or with some language you don't know, try adding this keyword.
Or, as with any developer, you're probably swamped with bugs. Some of these bugs will be lower priority than others. Try marking bugs that you realize you won't be able to any time soon as
helpwanted. Someone else with different priorities may see this and help you out.
When marking bugs (or RFEs)
helpwanted, be sure to add a comment carefully explaining what work needs to be done, and how to do it, if you know. The better you can explain the problem and its solution, the more likely it is that someone can provide a useful solution.
- Target Milestone
- The Mozilla project uses target milestones to plan Mozilla's
development process. If a bug is marked
mozilla1.3, it means an assigned developer picked Mozilla 1.3 as his/her estimate of the earliest milestone at which that bug might be resolved. This field should only be set by the person responsible for the bug.
- If a bug can't be fixed until another bug is fixed, that's a dependency. For any bug, you can list the bugs it depends on and bugs that depend on it. Bugzilla can display a dependency graphs which shows which the bugs it depends on and are dependent on it.
- Adding an attachment to a bug can be very useful. Test cases, screen shots and editor logs all can help pinpoint the bug and help the developer reproduce it. If you fix a bug, attach the patch to the bug. This is the preferred way to keep track of patches since it makes it easier for others to find and test. To make a patch, you need to generate a diff file containing the differences between the file with your changes and the original file in the repository. To generate a patch file enumerating changes for all files in the current directory try cvs diff -u > mypatch.diff. To apply a patch, go to the proper directory and patch < bugpatch.diff.
Life Cycle Of A Bug
What happens to a bug when it is first reported depends on who
reported it. New Bugzilla accounts by default create bugs which are
UNCONFIRMED - this means that a QA
(Quality Assurance) person needs to look at it and confirm it
exists before it gets turned into a
If you have been working in Bugzilla for a while and believe you
are worthy of being able to create
NEW bugs, mail
When a bug becomes
NEW, the developer will probably
look at the bug and either accept it or give it to someone else. If
the bug remains new and inactive for more than a week, Bugzilla
nags the bug's owner with email until action is taken. Whenever a
bug is reassigned or has its component changed, its status is set
NEW status means that
the bug is newly added to a particular developer's plate, not that
the bug is newly reported.
Those to whom additional permissions have been given have the ability to change all the fields of a bug (by default, you can only change a few). Whenever you change a field in a bug it's a good idea to add additional comments to explain what you are doing and why. Make a note whenever you do things like change the component, reassign the bug, create an attachment, add a dependency or add someone to the CC list. Whenever someone makes a change to the bug or adds a comment, the owner, reporter, the CC list and those who voted for the bug are sent an email (unless they have switched it off) showing the changes to the bug report.
If you are doing much work in Bugzilla, you might want to check out the QA Help Page, which has various useful resources and things to do.
When a bug is closed it's marked
RESOLVED and given
one of the following resolutions.
- A fix for this bug has been checked into the tree and tested by
the person marking it
- The problem described is not a bug, or not a bug in Mozilla.
- The problem described is a bug which will never be fixed, or a problem report which is a "feature", not a bug.
- The problem is a duplicate of an existing bug. Marking a bug duplicate requires the bug number of the duplicating bug and will add a comment with the bug number into the description field of the bug it is a duplicate of.
- All attempts at reproducing this bug in the current build were futile. If more information appears later, please re-open the bug, for now, file it.
QA (this could be you -
check out the QA help
page) looks at resolved bugs and ensures the appropriate action
has been taken. If they agree, the bug is marked
VERIFIED. Bugs remain in this state until the product
ships, at which time the bug is marked
may come back to life by becoming
Be careful when changing the status of someone else's bugs. Instead of making the change yourself, it's usually best to make a note of your proposed change as a comment and to let the bug's owner review this and make the change themselves. For instance, if you think one bug is a duplicate of another, make a note of it in the 'Additional Comments' section.
If you make a lot of useful comments to someone's bugs they may come to trust your judgement and ask you to go ahead and make the changes yourself, but unless they do, it's best to be cautious and only make comments.
Bugzilla is open source software. Its source code has been released under the Mozilla Public License. Check out the Bugzilla website if you would like to use the Bugzilla source to create a bug system for your own project.