For Testers‎ > ‎

Bug Life Cycle and Reporting Guidelines

Important links

Chromium (the web browser)

Chromium OS (the operating system)

You need a Google Account associated with your email address in order to use the bug system.

Bug reporting guidelines

  • Make sure the bug is verified with the latest Chromium build.
  • If it's one of the following bug types, please provide some further information:
  • Provide a high-level problem description.
  • Mention detailed steps to replicate the issue.
  • Include the expected behavior.
  • Verify the bug in other browsers and provide the information.
  • Include screenshots, if they might help.
  • If a bug can be reduced to a simplified test, then create a simplified test and attach it to the bug.
  • Additional Bug Reporting Guidlines for the Mac & Linux builds.
  • Additional Guidelines for Reporting Security Bugs.

Release block guidelines

Triage guidelines

Labels

Labels are used to help the engineering team categorize and prioritize the bug reports that are coming in. Each report can (and should) have multiple labels.

For details on labels used by the Chromium project, see Chromium Bug Labels.

Status

Open bugs

Status value Description
Unconfirmed The default for public bugs. Waiting for someone to validate, reproduce, or otherwise confirm that this is a bug.
Untriaged A confirmed bug that has not been reviewed for priority or assignment. This is the default for project members' new bugs.
Available Confirmed and triaged, but not assigned. Feel free to take these bugs!
Assigned In someone's work queue.
Started Actively being worked on.

Closed bugs

Status value Description
Fixed Fixed.
Verified The fix has been verified by test or by the original reporter.
Duplicate

This issue has been reported in another bug, or shares the same root cause as another bug. When Duplicate is selected, a field will appear for the ID of the other bug --- be sure to fill this in.

Mark the bug with less information/discussion in it as the Duplicate.

WontFix Covers all the reasons we chose to close the bug without taking action (can't repro, working as intended, obsolete).
ExternalDependency Bugs that turn out to be in another project's code and that we've filed with that other project. Useful for tracking known issues that manifest themselves in our product, but that need to be fixed elsewhere (such as WebKit and V8 issues).
FixUnreleased A special state for security hotfixes to mark bugs that are fixed, but not yet delivered to users. Bugs with this status will be visible only to project members and the original reporter.
Invalid Illegible, spam, etc.

Bug life cycle

  • When a bug is first logged, it is given Unconfirmed status.
  • The status is changed from unconfirmed to Untriaged once it has been verified as a Chromium bug.
  • Once a bug has been picked up by a developer, it is marked as Assigned.
  • A status of Started means a fix is being worked on.
  • A status of Fixed means that the bug has been fixed, and Verified means that the fix has been tested and confirmed. Please note that it will take some time for the "fix" to make it into the various channels (canary, beta, release) - pay attention to the milestone attached to the bug, and compare it to chrome://version.

Deciding where to submit your bug

Usually, Chromium-related bugs should be filed under one of the following projects:

Helping with bug triage

Read http://www.chromium.org/getting-involved/bug-triage if you're interested in helping with bug triage.

Infrastructure and build tools

If you find an issue with our infrastructure or build tools, please file the ticket using the Build Infrastructure template: