Important links

• Report bugs at http://code.google.com/p/chromium/issues/entry
• View existing bugs at http://code.google.com/p/chromium/issues/list
• Bug Reporting Guidlines for the Mac & Linux builds (with links to known issues pages)
  

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 the bug is a compatibility bug, provide a URL to replicate the issue.
• 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.

Labels

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

Label	Allowed values	Description
Type-value	Bug Feature Task Review Cleanup Other	The issue type. An issue can only have one type.
Pri-value	0 to 3	The priority. An issue can only have one priority value. 0 is most urgent; 3 is least urgent.
OS-value	All Windows Linux Mac	The operating system(s) on which the bug occurs.
Mstone-value	0.3,0.4,0.5,... X	A release milestone before which we want to resolve the issue. An issue can only be assigned to one milestone. Mstone-X is 'no milestone' (doesn't apply or not blocking any milestone).
Area-value	BrowserUI BrowserBackend Compat DevTools Installer Misc WebKit	The product area to which an issue belongs. A bug can belong to multiple areas.  BrowserUI  Browser features and chrome  BrowserBackend  Browser infrastructure (network, muti-proc, IPC, etc)  Compat  Unknown site compatibility and layout issues  DevTools  Development infrastructure (tools, tests, review, dashboards)  Installer Install, uninstall, download  Misc  Not classified  WebKit  Chromium-WebKit port and glue issues
private	-	Used for security bugs to make a bug visible only to project members and the reporter.

Some other labels include:

• NeedsReduction: this bug requires a reduced test case. See http://dev.chromium.org/for-testers/backend-testing/website-compatibility/reduced-test-cases.
• HasReduction: a reduced test case has been attached to the bug.
• AppCompat: issues with third-party software
• I18N: Internationalization issues (font selection and fallback, right-to-left display issues, IME, etc.)
• Regression: Features that worked in prior releases and are now broken. These should be Pri-1.

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. A comment should be added when a bug is closed as Duplicate, containing the active bug ID for this issue.
WontFix	Covers all the reasons we chose to close the bug without taking action (can't repro, working as intended, obsolete).
Upstream	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 either a Chromium or a WebKit bug.
• A bug that appears in Chromium as well as Safari is a WebKit bug and should be reported to bugs.webkit.org.
• A bug that appears only in Chromium is 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.

Filing Chromium bugs at bugs.webkit.org

If a chromium bug turns out to actually be a bug in WebKit, then use the following steps in deciding whether to file the bug at bugs.webkit.org.

1. Make sure to test the behavior in the latest WebKit nightly, Firefox, Chromium, Internet Explorer and Opera browsers.
2. If the bug does not happen in a WebKit nightly, but does happen in Chromium, then do not file the bug to webkit.org.
3. If any two of Firefox, Internet Explorer and/or Opera have the same behavior that is different from WebKit/Chromium, then file the bug at webkit.org.
4. If the intended behavior works in only one of Firefox, Internet Explorer or Opera or if every browser does something different, then apply the label "NeedsEngReview" so that a Chromium engineer can review the bug before taking further steps.