Confirming unconfirmed bugs 编辑

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:

• It is well-reported, according to the Bug Writing Guidelines.
• It is reported against a current build (one dated within the last two weeks).
• It's not an obvious duplicate; see for example the Most Frequently Reported bugs by dupe count.

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 current test version of the software you want to test such as
  • Latest Firefox Nightly - All Platforms
  • Thunderbird nightly build
  • Seamonkey
• Check out one of the following lists of UNCONFIRMED bugs  - Firefox, Core and Toolkit
• Check the Platform. We suggest that you check that you are confirming a bug on a relevant platform. You can sort the bugs by operating system, by clicking on the column header.

Get the proper Bugzilla 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 request it by doing one of the following these steps.

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:

• Your Mozilla Build ID (Type about:support in the URL bar)
• Your platform
• 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.

Examples of some questions you might want to ask in the bug to make it more actionable if you are unable to reproduce it:

1. Does the bug happen with the latest Nightly?
2. Does the bug happen when running in Safe Mode?
3. Does the bug happen in competing browsers?
4. Does the bug happen using other Firefox versions?
5. What are the detailed steps to reproduce?
6. Is there a minimized testcase or URL we can use to test?

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 highly encouraged

• 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 the crash signature to the appropriate field in Bugzilla (click the edit link to expand)
• Write a reduced test case.
• Find a URL that demonstrates the problem.