How to find previously reported bugs
The Mozilla developers want to hear about every specific and reproducible bug that happens when you use Mozilla, but it does not help to have the same bug reported many times. You can help to get more bugs fixed faster by checking the Bugzilla database before submitting your bug report, and not creating a duplicate report if the bug you found has been reported already.
If the bug seems obnoxious or obvious, or if you found it right away, or if you found it on a popular site, try looking at the Most Frequently Reported Bugs list first, to see if it jumps out at you. If it is a problem with basic functionality and you are using a nightly binary check the Smoketest Blockers to see if the problem is already known.
If you find that the problem you identified has already been reported, do not report it again, but if you have something useful to contribute, please do add a comment to the existing report.
Doing the Query
The Bugzilla Query Form looks dauntingly complex - it is complex and powerful—but you can safely ignore most of the form. Any part of the form that is left blank does not limit the search at all, and each part that is filled in cuts the list of bugs down to only those that match the criteria you set.
The Status field is set by default to find NEW, ASSIGNED, and REOPENED bugs—the unfixed bugs. But if you're using a milestone build, you should add RESOLVED and maybe VERIFIED (use Ctrl-click on MS-Windows, Command-click on MacOS), especially if the milestone is a few weeks old, since many bugs will have been fixed since your build was released.
In the Product field, you should use:
- Browser: If you are submitting a bug you found using the Mozilla 1.x browser, when composing an HTML page, or when basic browsing functionalities are not working (e.g. a website isn't displayed correctly, or downloading does not work), you should choose this product.
- Firefox: If you are using the Mozilla Firefox browser and something in the user interface isn't working correctly (e.g. a checkbox isn't working in the options dialog, or bookmarks can't be deleted) you should choose this product. If basic browsing functionalities like displaying a website do not work, the problem is most likely located in the backend code, so the Browser-product should be chosen.
- Mailnews: If you have found a bug using the Mozilla 1.x mail and news program or when basic mail/news functionalities are not working (e.g. You can't send mail, or you can't delete mail on your IMAP server), you should use this product.
- Thunderbird: If you are using the Mozilla Thunderbird mail/news program and something in the user interface is not working correctly (e.g. you can't compose a mail, or a checkbox isn't working in the options dialog) you should choose this product. If basic mail/news functionalities like connecting to an IMAP server or downloading a binary attachment do not work, the problem is most likely located in the backend code, so the Mailnews-product should be chosen.
- Most of the other items on this list will not apply if you are using the Mozilla Application or Mozilla Firefox and Mozilla Thunderbird. This will help focus the search.
Enter a word or short phrase that identifies the problem you saw as uniquely as possible in the Summary field. Examples: view source, auto proxy, drag drop, png image. If you enter more than one word and they are not a phrase, change the type of matching for the Summary field from contains the string to contains all of the words/strings or contains any of the words/strings, as appropriate (just to the left of the text-entry field).
Don't use the Keywords field without first clicking on the word Keywords: you can't type just anything in there. If you try to use this for keywords that are not on the list, it won't work, but some of the defined keywords may be useful to narrow down your search.
When you have done all that, click on the [Search] button. A new page will load, and on it you should see a list of bugs that match your query.
Looking Over the List
The "Bug List" page, by default, is ordered by priority and severity of bugs, so major problems and crashes should be at the top, and minor problems and enhancement requests at the bottom.
If you don't get a list, and get "Zarro Boogs found" (Zero Bugs) instead, look at the next section. If you get a very long list, look under Hey, not so many!, below. If the results of your query are totally unexpected, the Text Searching in Bugzilla tutorial may help you create a better query.
Otherwise, look for summaries that seem suggestive of the problem you have seen. Sometimes the bug that reports the problem you found will be obvious. Other times the only way to check will be looking at some of the bugs on the list. If nothing on the list looks relevant, try the strategies described in points 1 and 2 (and possibly 3) of the next section.
No Obvious Match
If you don't find a bug report that describes the same problem you found immediately, it might be a new bug, but there are other reasons that you might not find a match right away:
- The bug has already been reported and is in the database,
but the search you used didn't find it. If the bug you found
is obnoxious, you stumbled across it right away, and find it
everywhere you go, there probably is a report already, so
it's probably worth trying at least one more search.
- You can go back and search in another way, using a synonym or another word entirely.
- If that doesn't help, try putting your search word or phrase in the Description entry field instead. Or try changing the type of matching for the Summary or Description fields from "case-insensitive substring" to "all words", "any words", or "regular expression".
- You should use as short a word form as practical when using the (default) "case-insensitive substring" matching type - for example "wheel" will find all of the bugs findable with "wheel mouse" "wheelmouse", "mousewheel" and "mouse wheel" - although, as you may guess, this might also find bugs that have nothing to do with mice.
- You mistyped something on the search form. Typos can happen to anyone: if you can't believe you got no hits, go back and look at your typing.
- The bug is already fixed. If it has been more than a few days since the version of Mozilla you found the bug with has been released, especially if it is a Milestone release, and especially if the bug is obnoxious, easy to find, and/or wasn't there earlier, it is more likely to get immediate attention. You can try going back to the query page, and in the upper-left corner, under Status, and add RESOLVED and VERIFIED to include the bugs that have been fixed (use Ctrl-click on MS-Windows, Command-click on MacOS).
If you've checked and are pretty sure that the bug has not been reported already. Or if you don't want to take a chance on it not getting reported, skip to the My Bug Looks New section below.
Hey, Not so Many!
If the bug list you get is too long or too diverse, it is best to try again with different or additional search words, or use the "all words", or "regular expression" matching type to focus the results. The Text searching in Bugzilla tutorial describes what each matching type is best for, and has an introduction to using regular expressions for searching.
If the bug list you get is long, but not scattered, there are a few things you can do to make it more manageable.
- If you find one that has a similar issue, look at what Component that bug report is filed against (on the right, near the top), go back to the query page, and select that component from the list under Components. You can also click on that label to see descriptions of each component to try to find the appropriate one. Alternatively, you can use the Change Columns link at the bottom of the Bug List page to add the "Components" column, and sort by that).
- Look near the top for crashes and hangs (Mozilla stops responding), in the middle of the list for most bugs, and near the bottom for minor problems and enhancements.
- Look at a few of the bugs on the list anyway to try to get a better idea of the type of language used in existing bug reports, then try a more specific search word or phrase.
- If you can think of a second word that characterizes the problem, try doing a search on the Bug List page to find the bugs whose summaries also include that word (use Search>Find in this Page or Edit>Find in Page).
- Try sorting the list: each of the headings can be clicked on to sort the list by that field.
- If you are absolutely sure that this bug could only apply to a certain platform and/or operating system, you can limit the search by using the appropriate fields on the first row.
It Looks Like a Match
If you find a bug that appears to be about the same problem that you saw, please read it through to be sure. If it is a match, please do not submit a new bug report; instead add to the existing report if you have anything new to contribute. You may wish to add a vote to that bug if you think it is important. Thank you for saving the developers the time needed to identify another duplicate report.
If you have a detail to add, or if you are using a different platform than is mentioned to date in the report, or if you can confirm the problem and more than a month has gone by since the latest comment, you can type a comment into the Additional Comments field. Please look over what you add before clicking on the [Commit] button.
If you included RESOLVED and VERIFIED status bugs in your search, you might actually find that your bug matches one that has a Resolution of DUPLICATE. If that happens, please follow the link at the bottom of the comments that looks like "This bug has been marked as a duplicate of 00000" and add your comments there.
My Bug Looks New
If you do not find a bug that appears to be about the problem you saw, go ahead and submit a bug report. Please, though, be sure to report the Build ID of the Mozilla that you used, specific steps to reproduce the problem, and describe both what happened and what should have happened. Use Bugzilla to file bugs, following the Bug Writing Guidelines to help you include the information that is needed.
Put in as much relevant detail as you can (if you're not sure about the relevancy, include the detail). Be as specific as possible. Please make sure that you can reproduce the bug before reporting it.
Please do not mention multiple problems in one bug report; if you have seen more than one problem, keep each one distinct and separate, filing another report if necessary. Please look over your writing before clicking on the [Commit] button.
(Thanks to Christine Begle, Eli Goldberg, Simon Paquet and Terry Weissman for contributing to this document. Additional suggestions welcome.)