last update: 2017/07/11
The current triage process owner is mpearson@.
Instructions for Chrome omnibox engineers serving an assigned bug triage rotation.
Every omnibox bug is triaged, preferably within a week of being filed. This means making the issue clear, marking it as a dup if necessary, revising the status, setting a priority, labeling/categorizing as appropriate (or handing off to another component), and (possibly) assigning an owner. The only reason bugs should remain untriaged (i.e., status=Unconfirmed or status=Untriaged) is because of they need additional information from someone. These bugs should be labeled as such (Needs=Feedback or Needs=TestConfirmation).
Other team members are welcome to triage a bug if they see it before the the triage engineer. The triager owner will cycle among team members by arrangement.
The purpose of labels, components, and priority are to make it easy for omnibox team members to identify bugs at a glance that affect a particular area. In other words, this bug management process is intended to make the team more efficient and provide better visibility for team members to identify what’s important to work on in particular areas.
If the bug isn’t clear, or the desired outcome is unclear, please apply the label Needs-Feedback and courteously ask for clarification. This is appropriate both for external bug filers, Chromium developers on other teams, or Googlers. The label is merely an indication that this bug needs information from someone outside the team in order to make progress. It’s also an indication that someone on the team needs to follow-up if feedback is not forthcoming.
Often the appropriate request includes a request for chrome://omnibox data; an example such request is below.
Also, if the bug is clear, try to reproduce. If it cannot be reproduced or you lack the necessary setup, either ask the reporter for clarification or add the label Needs-TestConfirmation as appropriate.
Some bugs are feature requests. Marks these as Feature, not Bug. It’s likely a feature may have been requested before. Search the bugs database and dup appropriately.
Some commonly requested features and commonly reported bugs are listed below.
Set the Status field to the following value depending on the triage action taken:
Follow standard Chromium policies. Priority-2 represents wanted for this release but can be punted for a release. Priority-3 are bugs not time sensitive. There is an even-lower-priority state; see the NextAction=01/08/2019 below.
Generally only assign someone else to own a bug if the bug is Priority-2 or better. Priority-3 bugs are not likely to be completed soon; for these bugs, don’t assign an owner to merely sit on the bug. To draw someone’s attention to a bug, explicitly CC them.
Omnibox bugs use a combination of labels (including hotlists) and subcomponents to indicate their topic.
Most omnibox bugs should be in the main omnibox component. A few will fall directly into a subcomponent instead; the available subcomponents are listed below.
Add all the labels, components, and next actions dates that seem appropriate to the issue. The main ones encountered by omnibox issues are listed below; feel free to use additional suitable ones as well.
The main labels that apply to bugs include:
| Label | Description |
|---|---|
| Hotlist-OmniboxFocus | Bugs about focus, including not having focus when it should, focussing on the wrong end of the URL, etc. (Note: label does not appear in the Hotlist completion dropdown.) |
| Hotlist-OmniboxKeyboardShortcuts | Bugs related to handling of keyboard shortcuts, including both incorrectly handling real omnibox shortcuts and preventing other Chrome shortcuts from working when focus is in the omnibox. (Note: label does not appear in the Hotlist completion dropdown.) |
| Hotlist-OmniboxRanking | Bugs related to which suggestions are considered matches against the input and how relevance scores are assigned. (Note: label does not appear in the Hotlist completion dropdown.) |
| Hotlist-CodeHealth | Bugs about the making the code base easy to work with such as quality of comments. Refactoring efforts can also be included when for that purpose. |
| Hotlist-Polish | Bugs about how a feature looks and feels: not whether the feature works or not; instead, more of whether it appears the feature was created with attention to detail. Often user-visible edge cases fit in this category. |
| Hotlist-Refactoring | Bugs related to restructuring existing code without changing its behavior. |
| Performance-Browser | Bugs that affect performance. |
The components that additionally apply to bugs include:
| Component | Description |
|---|---|
| Enterprise | Bugs that mainly affect enterprise environments: enterprise policies, intranet handling, etc. |
| Tests>{Disabled,Failed,Missing,Flaky} | Bugs related to failing tests or lack of test coverage. |
| UI>Browser>Search | Bugs related to web search in general whose effects aren’t limited to the omnibox. |
The subcomponents of omnibox bugs include:
| Subcomponent | Description |
|---|---|
| UI>Browser>Omnibox>AiS | Answers in Suggest. |
| UI>Browser>Omnibox>SecurityIndicators | Secure/insecure icons; triaged by another team. |
| UI>Browser>Omnibox>TabToSearch | Custom search engines, omnibox extensions, etc. (including adding, triggering, ranking, etc. for them). |
| UI>Browser>Omnibox>ZeroSuggest | Suggestions displayed on omnibox focus (both contextual and non-contextual). |
If the bug is extremely low priority, set the NextAction field to 01/08/2019 and mention that we will “reassess” the bug next year. This NextAction field is for Priority-3 bugs that are somehow less important than other priority-3 bugs. These are bugs we’re sure no one on the team intends to fix this year (e.g., really unimportant, or mostly unimportant and hard to fix). This label should be applied only when confident the whole team will agree with you. When searching the bugs database for things to do, I suggest excluding bugs on this hotlist.)
NOTE: If you ask someone for chrome://omnibox data on a public bug, label the bug with Restrict-View-Google so that any personal data from the reporter's chrome://omnibox output is not made public. Do this before they respond. As the original reporter, they should still have access to the bug even with the restrict applied.
Example request:
Please submit chrome://omnibox output for “___”. Check both the “show all details” and “show results per provider” boxes. This will help us figure out what's going on.
Feel free to paste the results in here unformatted; we’ll be able to decipher them.
“I want the option to turn off inline autocomplete.” Dup against crbug/91378.
“I typed in something like go/foo and got redirected to a search results page instead.” See this internal page. Follow the guidelines there; generally ask about a message about profile corruption. If so, the bug can be dupped against crbug/665253
“I want to disable suggestions from appearing entirely”. Try to find out why. Quote freely from pkasting’s comment on this bug.
General Chromium bug triage guidelines
Omnibox bugs that we intend/hope to tackle this year, broken down:
User-facing (everything not tagged as one of the non-user-facing categories below). Some of these can be further categorized: Performance, Polish, Enterprise, Answers in Suggest, Tab To Search, Zero Suggest.
Non user-facing, divided into these categories: