Chromium DevTools Issues Guidelines

goo.gle/chromium-devtools-issues

This document explains how Chromium DevTools (related) issues are tracked in the Chromium>Platform>DevTools component tree of crbug, how we define and manage priorities and Service Level Objectives (SLOs), as well as the overall bug life cycle.

In 2024 the Chromium project migrated crbug to the Google Issue Tracker, called Buganizer internally. While most of the functionality is generally available to all Chromium contributors, some of it is limited to Googlers, and can only be accessed via Buganizer internally.

Bug reporting guidelines

The process for reporting a bug in Chromium DevTools follows the Chromium-wide Bug Life Cycle and Reporting Guidelines, and we encourage you to first read through the How to file a good browser bug article. Proceed according to the check list below:

  1. Try to verify that it is indeed a bug and not the intended behavior of a certain feature.
  2. Check if there is already a bug report for it, by searching in the list of Open Chromium DevTools Bugs. If you find an existing bug report, click the +1 button in the upper-right corner of the page to indicate that you are also affected by this.
  3. If there's no existing bug report that matches your issue, start reporting a new bug.

Report the bug

You can use the shortlink goo.gle/devtools-bug or the Help > Report a DevTools issue menu item to start a new bug report.

Report a DevTools Issues

You might need to login to the Google Issue Tracker first with a Google account in order to proceed from there. Afterwards the Defect from user template opens, where you can describe the bug. Note that the template defaults to Markdown (with a preview below the text input box).

Create Issue Template

  1. Please enter a meaningful title.
  2. Replace <from chrome://version/> and <OS version> with the relevant version information.
  3. Outline exact steps to reproduce the problem. Make sure to provide steps that are easy and accessible. Ideally create a minified test case on glitch.com or GitHub. Also make sure to include screenshots and videos that help us to reproduce and understand the problem you are facing.

Overview

Check out the Issues Overview for a general introduction to the Google Issue Tracker. This section provides an overview of the Chromium DevTools specifics.

Issue types

crbug supports a wide range of different issue types, with ambiguous semantics. For Chromium DevTools we explicitly limit the set of types we use and give them well-defined semantics:

Issue TypeMeaning
BugThe behavior does not match what is supposed to occur or what is documented. The product does not work as expected.
Feature RequestThe product works as intended but could be improved.
Internal CleanupThis is typically a maintenance issue. The issue has no effect on the behavior of a product, but addressing it may allow more intuitive interaction.
VulnerabilitySecurity vulnerabilities subject to the handling outlined in Google's Vulnerability Priority Guidelines.
Privacy IssuePrivacy issues subject to the handling outlined in Google's Privacy Issue Bugs.
TaskA small unit of work.
ProjectA goal-driven effort with a finite start and end, focused on creating a unique product, service, or result.
FeatureA collection of work that provides a specific value to the user.

The first 6 (Bug to Task) are used for day-to-day work and for issues reported by users. The last 2 (Project and Feature) are used to organize the other types of issues for the purpose of planning (ahead). We explicitly don't use Customer Issue, Process, Milestone, Epic, and Story within Chrome DevTools.

BEST PRACTICE: Limit the nesting of Project and Feature to the bare minimum needed, and use Task for small chunks of work.

Parent-Child Relationships and Blocking

TL;DR:

  • Prefer parent-child relationships to split work into smaller chunks.
  • Prefer blocking to express dependencies between independent / adjacent issues.

When splitting up work into smaller chunks or when scoping a project that encompasses multiple bugs or feature requests, favor to express this via a parent-child relationship. Consider the example of a CSS Nesting:

  1. This should start with an issue of type Feature which is about adding CSS Nesting support to Chromium DevTools.
  2. This Feature has child issues of type Task, which are concerned with adding CSS Nesting support to the various parts of DevTools involved, for example the CDP (Chrome DevTools Protocol), the Elements panel, the Sources panel, and so forth.
  3. Over the course of the project there'll likely also be Feature Requests and Bugs from internal and external developers, which should also be parented under the CSS Nesting Feature issue.

Priorities

Below is a table to guide how to think about priorities, aligned with Chromium's Triage Best Practices:

PriorityTimelineDescription
P0
(emergency)
Requires immediate resolution.Regressions which are substantially impacting existing users, partners, or developers.
High-risk security issues affecting the stable channel.
Situations that create large, urgent, legal or financial risks for Google.
P1
(priority engineering work)
Needed for target milestone.Major Regressions.
Work requiring prompt resolution.
Work that has to get done before the targeted release.
P2
(active engineering work)
Wanted for target milestone.Non-urgent issues.
Important issues that are worked on as best effort, without a milestone.
Polish or bug fixing work in areas where the team has decided we want to invest.
P3
(later, want to do)
Not time sensitive.Something we want to do, but not right now.
Legitimate issues that we will work on when we have the cycles to do so.
P4
(later, maybe never)
Some day... or never.Nice to have, but also fine not to have.

Components

The following components in crbug are owned by the Chrome DevTools team.

ComponentDescription
Chromium>Platform>DevToolsIssues that don't fit any specific category
Chromium>Platform>DevTools>AccessibilityDevTools' accessibility
Chromium>Platform>DevTools>AIConsole Insights and AI Assistance panel
Chromium>Platform>DevTools>AnimationsAnimations panel
Chromium>Platform>DevTools>ApplicationApplication panel
Chromium>Platform>DevTools>ConsoleConsole panel
Chromium>Platform>DevTools>ElementsElements panel
Chromium>Platform>DevTools>InfraIssues related to DevTools' infrastructure
Chromium>Platform>DevTools>IssuesIssues panel
Chromium>Platform>DevTools>MemoryHeap/Memory Profiling, Memory Analysis
Chromium>Platform>DevTools>MobileMobile Emulation / Debugging
Chromium>Platform>DevTools>NetworkNetwork, Network conditions, Network request blocking panels
Chromium>Platform>DevTools>PerformancePerformance, Performance Monitor, Performance Insights panels
Chromium>Platform>DevTools>ExtensionsIssues related to DevTools extensions and extensibility
Chromium>Platform>DevTools>RecorderRecorder panel
Chromium>Platform>DevTools>SecuritySecurity panel
Chromium>Platform>DevTools>SourcesSources panel
Chromium>Platform>DevTools>UXUsability and interface issues
Chromium>Platform>DevTools>WebAssemblyWebAssembly issues

Hotlists

The Chrome DevTools TaskFlow Hotlists bookmark group contains all the hotlists relevant to issue management for Chromium DevTools (in particular via the Google internal Chrome DevTools TaskFlow).

In particular we use the following Chromium-wide hotlists.

HotlistDescription
Chromium-RegressionHotlist used to track user-noticeable regressions across Chromium.
Needs-FeedbackUsed by the TEs and the Triage Gardeners to request more feedback on an issue. The Chrome Blintz service will automatically remove the label once the reporter provides more feedback.
TE-NeedsTriageHelpUsed by TEs when they cannot confirm a new issue and request help from the engineering team.
UnconfirmedAll user reported issue start their life on this hotlist. TEs do a first level triage and try to reproduce the problem, and afterwards either close the issue, or remove it from this hotlist, and therefore forward it to our TaskFlow Inbox.
User-SubmittedPart of the DevTools Issue template, all user reported issues start life on this hotlist.
Note: We don‘t actively monitor or utilize the Available hotlist, however, meaning that we aren’t fully aligned with the Chromium-wide triage guidelines. In particular, for Chromium-wide dashboards that utilize Available as an indicator for the triage status, Chromium DevTools might show up with a high percentage of untriaged issues due to this fact.

T-Shirt Sizes

We use the T-Shirt sizes approach to estimate effort for the Chromium>Platform>DevTools component tree, based on the following guidelines:

SizeDescriptionExamples
XXSSmall CLStyles bar loses focus in Chrome OS DevTools, Add 20x CPU throttling preset, Remove ‘Consistent source map variable experiment’, Autofill tab breaks with phone numbers starting with ‘+’
XSMedium-sized CL or series of trivial CLsLocal overrides for New Tab Page misses one “/” in folder name, Memory tool should highlight common problems and opportunities, Improve the developer experience of using compression dictionaries
SLarge-sized CL or series of non-trivial CLsExcluding sensitive data from HARs (HTTP Archives) by default
Mquarter-long single-person projectExceptions in promise constructor should be treated as promise rejection
Lmulti-quarter or -person projectReplace regex-matching in the StylesSidebarPane
XLmulti-quarter and -person projectMPArch migration, GM3 adoption
XXLmulti-year project with a dedicated teamPerformance Insights

SLOs

In order to deliver a better product experience for developers using Chromium DevTools we want to

  1. reduce the number of regressions that ship to the (Chrome) Stable channel, and
  2. reduce the number of bugs overall.

The following SLOs (Service Level Objectives) apply to issues of type Bug, Vulnerability, and Privacy Issue. other types of issues such as Feature Request or Task are out of scope for SLOs (with the notable exception of Postmortem action items, where Chrome also enforces SLOs for non-bug issues). We also explicitly restrict these SLOs to bugs in crbug, and are not concerned with bugs that are tracked in other places such as GitHub. Below is a high level summary of our SLOs (Googlers can check the Chrome DevTools SLO Policy and Chrome SLO Policy for more details):

AssignmentResponseClosure
P01 business dayEvery business day1 week
P11 week1 week4 weeks
P22 months-6 months
P31 year--

The first two rows are identical to go/chrome-slo, with the last two rows being specific to Chrome DevTools. crbug provides a Nearest SLO column that surfaces SLO violations easily:

Nearest SLO in crbug

Release Blocking Issues

In accordance with go/chrome-slo there are special SLOs for issues that are severe enough to block a release shipping to users (see go/chrome-release-slos). They apply to bug types in the same way as the above SLOs.

AssignmentResponseClosure
Urgent1 dayEvery day2 days
Standard2 daysEvery 2 days10 days

Email Reports

Googlers only: Buganizer provides a nice feature that allows you to subscribe to Email Reports for your SLO (violations). Just go to Settings in Buganizer and enable Subscribe to your own reports under SLO Reports.

Subscribe to SLO Email Reports

This will get you a daily email (or whichever cadence you prefer) from Buganizer in your Inbox that shows you up to 25 P0 and P1 out-of-SLO issues.

Dashboard

Googlers only: You can use the Buganizer SLO Compliance dashboard, which is refreshed every 2-4 hours, to see SLO compliance for a given lead.