You are currently viewing a snapshot of taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to, please file a bug.

Bug Triagers' Guide

Moving a Bug from Unconfirmed to New

Bugs from new bug reporters will initially have the status UNCONFIRMED. To move a bug from UNCONFIRMED to NEW, we need your help to verify that the bug is valid.


A bug can be moved from UNCONFIRMED to NEW if:

Note that you do not necessarily have to be able to reproduce the bug in order to confirm it.

In order to help confirm bugs, you need to do the following:

Get Set Up

  • Download a Firefox current nightly build.
  • Check out one of the following lists of UNCONFIRMED bugs - Linux only - PPC Mac only - Intel Mac only - Windows only - All (note that "All" doesn't mean unconfirmed bugs reported with "Platform: All", it means every Unconfirmed bug.)
  • Please check the list of bugs pertaining to your platform first. It might be good to click on the "Sev" column header to sort by severity.

It's probably better to use Bugzilla's Back/Forward links to move through the list than reload it every time you want to look at a new bug.

Get the Right Privileges

In order to confirm bugs, you need the "canconfirm" privilege.
If you've been active in Bugzilla, you may already have this privilege. Check your Bugzilla preferences. If your Permissions include "Can confirm a bug", then you are all set.
If you don't have this privilege, you can get it by doing one of the following.

  • If you haven't filed a lot of bugs, first go through all the steps under "Confirm the Unconfirmed" for three bugs.
  • Mail Gerv with full URLs to the bugs.
  • If everything looks okay, you'll then get the "can confirm a bug" privilege.

Confirm the Unconfirmed

  1. Try to determine whether the bug is a duplicate.
    Use this form to search the database.
  2. Try to reproduce the bug.
    If you are able to reproduce the bug, note the fact that you could reproduce the bug, and add these comments to the Additional Comments field:

    1. Your Mozilla Build ID (the title bar of the browser)
    2. Your platform
    3. Your operating system

    If you are unable to reproduce the bug, note in the comments that you tried to reproduce the bug and could not. If others agree that the bug is unreproducible, you can mark it INVALID or WORKSFORME, and tell the reporter to reopen it if they can provide steps to reproduce the bug in a current build. Boilerplate text for common bug problems can be found at the bottom of this page.

  3. Make the bug easy to understand.
    See the bug writing guidelines for the kind of information that is useful in a bug, including steps to reproduce and a good description.
  4. Check the Product and Component.
    If the bug report is classified incorrectly, move to the correct Product and Component. Be sure to click the radio button that says "reassign the bug to owner of the selected component."
  5. Check the bug's Summary.
    Update the Summary so that it is descriptive, and contains enough key words so that people searching for this bug will find it.
  6. Change the status to NEW.
    You should only confirm a bug when it's not in the General component.

Optional, but Helpful

  • Add Keywords. If you are familiar with keywords and their meanings, please add the right keywords.
  • Update severity so that it corresponds to the Bugzilla guidelines.
  • Add a stack trace for crashing bugs.
  • Write a reduced test case.
  • Find a URL that demonstrates the problem.