BMO/How to Use Bugzilla

How to use Bugzilla(.mozilla.org)

This is currently a draft for a Bugzilla Users' Guide specific to bugzilla.mozilla.org users -- bug reporters, people submitting fixes, code reviewers, triagers, release teams, and others. (This guide may be merged eventually into a new Users' Guide for BMO hosted in readthedocs.)

BMO vs Bugzilla

What is Bugzilla, what is bmo, and how are they different?

Bugzilla is an open source project that anyone can download and install, run by volunteers.

Bugzilla.mozilla.org, or BMO, is a specific implementation of Bugzilla, with extra extensions and customizations, maintained by Mozilla.

This page, How to Use Bugzilla, is a help page for http://bugzilla.mozilla.org.

The BMO team has its own set of wiki pages useful for developers and other community members who'd like to contribute.

How to report a bug

To report a bug, you will need an account on https://bugzilla.mozilla.org/.

Creating a Bugzilla Account

There are two ways to create an account on bugzilla.mozilla.org.

1.Create an Account

2.Log in With GitHub

If you have a GitHub account you can use it to log in.

First click "Log in".

Then click the Octocat/GitHub logo.

If you are signed into GitHub you'll be asked if you want GitHub to login to bugzilla.mozilla.org on your behalf and what information about your account will be shared from GitHub with us. If you aren't signed in, GitHub will ask you to login, then if you want to be asked if you want GitHub to be able to login on your behalf. You'll be identified by the email address you use on GitHub.

Three Things Your Bug Should Have

Bug triagers, developers, and QA folks will need to be able to understand and reproduce the bug.

• Give the bug a specific and descriptive summary.
• Describe the exact steps to make the bug happen again.
• Attach a screen shot, a link, or code, if that will help others understand the bug.

Bugzilla Helper

If you're new to bugzilla.mozilla.org, reporting a new bug takes you to the Bugzilla Helper form (you can also always find it at https://bugzilla.mozilla.org/enter_bug.cgi?format=guided). The Helper form walks you through three steps in filing a bug.

Before starting to log a new bug is important to:

• Make sure that the issue is still reproducible and it was not only a one time issue
• Make sure that the issue is reproducible with a clean profile
• Make sure that the issue is reproducible only on Firefox browser and is not a problem with the website. Try to reproduce the issue on other browsers(eg. Google Chrome)
• Make sure that the issue is not already logged

Logging a new bug

Step 1 of 3: Choose a product.

Depending on what you are reporting, there may be better options than Bugzilla. The top section lists some of this, including Mozilla's Support and Feedback sites.

If your bug is in a Mozilla product, select it from the list under "None of the above; my bug is in:". It might in Firefox(for bugs found in Firefox web browser), Firefox for Android, Firefox for iOS, or some other product. Click the one that is your best guess.

Step 2 of 3: Summarize the bug.

Write a short summary of your bug. It should be specific, clear, descriptive, and searchable. Think of it as a title for the bug. There is also a specific option for translation errors.

After you type in your bug summary, click the "Find similar issues" button. You will get a list of bugs that may be similar to yours.

There is good news and bad news here! The bad: there isn't necessarily an easy way to judge if your bug has already been filed. It takes a little bit of reading and thought. The good news is that scanning this list can help you avoid making a duplicate bug, and keep you informed on related issues.

For this list of similar issues, you may be able to tell from one of the summaries that your bug has already been reported by someone else. Or, to look deeper into the similar bugs, click on a bug number in the left-hand column, opening it in a new tab. Maybe you can tell that it's the same as the bug you intended to file. If the bug is still open, you can click "Follow bug" in the rightmost column if you want to be emailed when there are updates to the bug.

If you don't find your bug, you can create a new bug report by clicking "My issue is not listed".

Step 3 of 3: Describe the bug.

Bugzilla Helper gives you three questions to answer.

• "What did you do?" This helps other people to try to recreate your bug.
  • For a good understanding of the issue, this section must contain:
    • The OS on which the issue was found (eg. Windows 10x64)
    • The Firefox build (eg. Firefox 58.0.1, or Firefox 60.0a1(2018.01.01), build ID...)
    • All the steps performed in order to reproduce the issue. For example:
      • 1.Launch Firefox.
      • 2. Go to https://www.youtube.com
      • 3. Start a video.
• "What happened?" where you can explain the bad or buggy behavior.
  • In this section it must be described exactly what happens after steps from ‘What did you do?’ section are followed. For example:
    • The video is not working. Error message is displayed.
• "What should have happened?" where you explain the correct or desired behavior.
  • In this sections, is listed exactly what is expected to happen after following the steps from the “What did you do?” section. For example:
    • The video is correctly played.

There are a few other options that may apply to your bug.

• Attach a file - at this section, a screenshot or a screencast of the actual result can be attached. This will help for a better understanding of the issue.
• Security - this checkbox is expected to be checked only if a security issue is found and it must be hidden from the public.
• Additional Details - this section is available only if selecting ‘Firefox’ product in order so verify that this issue is also reproducible on phone or tablet.

Notes

• In “Version:” section, the Branch can be selected. For example:
  • If the issue is found on Firefox 60.0a1, the “60 Branch” is selected
  • If the issue is reproducible on two, or more than two branches, than “Trunk” is selected
• If a crash is encountered, the ID from about:crashes must be pasted in the ‘What happened?’ section
• Is important to add any additional details in the logged bug
• A more detailed description can be found on the Bug Guidelines wiki page

Conclusions

Writing good, detailed, bug reports may, on one hand, consume time when they are created.

On the other hand, a lot more time would be consumed in the future because of incorrect or incomplete bug reports, when:

• You are required to explain the steps, as the developer is not able to reproduce the issue;
• You have to retry reproducing it, in order to be able to test the fix, after a long time has passed between creating the ticket and solving it;
• The developer, or the entire team, has to investigate and start working on a fix, without being able to get in contact with the reporter;

Writing good bug reports is not a “born with” talent. It’s improved with time, experience and correct attitude.

Once you're used to filing bugs, you can switch to the advanced bug entry form.

There's a detailed guide to making your bug as well formed as possible: the Bug writing guidelines on MDN.

needinfo flag

If you have a question about a bug, and you'd like to direct that question to a specific person, you can do that easily with the needinfo flag.

The person you need info from will get bugmail with (look up the X-Bugzilla-header) in the header. This may get a person's attention faster than adding them to the CC list of a bug.

You can see the needinfo flags you have requested of others and the ones requested of you in your Dashboard.

Dashboards

Trying to answer the "What should I do today" question? Go no further than the dashboards.

My Dashboard

My Dashboard, or actually your Dashboard, has some nice options for viewing lists of bugs that may be of interest to you.

Bug triage

Bug triage documentation

Products and components

Bugs in bugzilla.mozilla.org are organized into a hierarchy of categories. Products are high level categories such as Core, Firefox, Firefox for Android, Firefox iOS, or Toolkit.

This is the list of products on BMO: https://bugzilla.mozilla.org/describecomponents.cgi

From this product list, you can click on a product name to see a list of the various components it contains.

When you file a new bug, it can be difficult to know exactly where to file it. People who help manage and triage bug reports often move new bugs into a product and component that is a better fit. This helps bring the bug to the attention of developer teams who may be best equipped to fix it.

Product and component are usually referred to with separating colons; Core::WebRTC or Firefox::General.

Incoming bug reports filed by users new to BMO and that are in the product Firefox automatically are directed into the Untriaged component.

Components can be useful for managing bugmail. Using component watching, you can set up bugmail for all bugs in a particular component.

Searching bugzilla.mozilla.org

Why do we have so many ways to search bmo, and how do they work?

Quicksearch

Quickseach rocks! You should use it.

Advanced search

Advanced search looks hardcore, but the rewards for learning how to drive it are plentiful.

Search pronouns

also, pronouns are amazing

Preferences

Bugmail

bugmail filtering (via x- headers)

too much bugmail? filter!

Bug tagging

Want to organize or keep track of bugs? Use tags.

You can tag a bug with something that will help you find it later in a search. Or you may be tagging a bug to bring it to the attention of a person or a team.

There are three ways to tag in BMO: whiteboard field, keywords, and saved search tags.

Keywords

These are a limited set of keyword tags, set by teams and people with admin privilege. You can start typing a tag and get a dropdown menu of all the keywords currently available. Keywords like "regression" and "crash" are used by engineering, release, and QA teams, for example.

Whiteboard

The whiteboard field is for free tagging. It's used both by teams and by people who want to track bugs they're interested in.

Bugzilla tips: http://bugzillatips.wordpress.com/2010/11/23/tagging/

Saved search tags

At the bottom of every page in BMO you will see the option to "Add the named tag ___ to bugs ____". Tags you create here are private to you by default, though you can share them with groups (through the saved search interface).

tracking flags

tracking-firefox-60? Who's doing the tracking? Should I set these flags? When and why?

Tracking flags are used by developers, triagers, QA and the release management teams to keep track of bugs whose fixes are slated to go into a particular product release. Flags of the form tracking-firefox-60 have a ?, +, or - associated.

For example, a search for tracking-firefox-60 and "+" currently shows around 20 bugs.

If you would like to suggest a bug and its fix be considered (by release managers) for a particular release, mark it with that release and a question mark. This might be good to do for a bug that's been fixed in one release channel but needs to be uplifted to another.

APIs (xmlrpc, jsonrpc, jsonp, rest)

I hear you want to integrate with bmo. Where to start, what to do next, and best practices which won't get you blocked.

Getting a copy of the database

Before you point wget at bmo, we can give you a dump of the database. Really.

Here are database copies for 2013 in a temporary location: http://people.mozilla.org/~mhoye/bugzilla/

Reports

For when advanced searching isn't advanced enough. . .

Whining

BMO can automatically send you buglists. This requires that you have canconfirm.

Permissions and groups

If you would like to be able to change the status of bugs from UNCONFIRMED to NEW, you will need the canconfirm permission. It also allows you to file a bug as NEW rather than as UNCONFIRMED, which is the default for bugs filed by new users to bugzilla.mozilla.org.

The editbugs permission gives you the ability to edit most fields of a bug. It's very useful for adding good information to a bug, and for making summaries more clear and descriptive.

Here's how to ask for canconfirm and editbugs permissions on BMO:

https://wiki.mozilla.org/BMO/UserGuide#Permissions_and_Groups

There are many other groups, some team-specific, some for security reasons, and some that are for corporate confidential bugs or comments. By default, everyone is in the BMO group "everyone". Your permissions affect which shared searches you can see. When you create a saved search of your own, you can choose to share it with any group that are in.

You can see your groups and permissions here:

https://bugzilla.mozilla.org/userprefs.cgi?tab=permissions