The query page is broken down into the following sections:

Bug Settings
People Involved
Text Search Options
Module Options
Advanced Querying
The Bottom Of The Form

"I already know how to use Bugzilla, but would like information about Bugzilla and the author of this document."
"Ok, I am almost certain the bug I discovered isn't in Bugzilla, how do I submit the bug?" - Read the guidelines first!

Back to the Query. If you typed anything in the forms already, you might want to hit back on the browser. When you are all done reading, do a sample query!

Status

• UNCONFIRMED - Nobody has validated that this bug needs to be fixed. Users who have the correct permissions may confirm this bug, changing its state to NEW. You can view your permissions here. A bug may be directly resolved and marked RESOLVED but usually a bug will be confirmed by the person to whom it is assigned. Usually, an UNCOMFIRMED bug will be left uncomfirmed until someone has verified that the bug the reporter submitted actually occurrs.
• NEW - This bug has recently been added to the assignee's list of bugs and must be processed. Bugs in this state may be accepted, and become ASSIGNED, passed on to someone else, and remain NEW, or resolved and marked RESOLVED.
• ASSIGNED - This bug is not yet resolved, but is assigned to someone who thinks they can fix it. From here bugs can be given to another person and become NEW, or resolved and become RESOLVED.
• REOPENED - The bug was once resolved, but the resolution was deemed incorrect. For example, a WORKSFORME bug is REOPENED when more information shows up and the bug is now reproducible. From here bugs are either marked ASSIGNED or RESOLVED.
• RESOLVED - A resolution has been made, and it is awaiting verification by the QA. From here bugs are either re-opened and become REOPENED, are marked VERIFIED, or are closed for good and marked CLOSED.
• VERIFIED- QA has looked at the bug and the resolution and agrees that the appropriate action has been taken.
• CLOSED - The bug is considered dead, the resolution is correct, and the product the bug has been reported against is terminated or shipped. Any zombie bugs who choose to walk the earth again must do so by becoming REOPENED. This state is rarely ever used.

Resolution

The resolution field indicates what happened to this bug.

No resolution yet: All bugs which are in one of the "open" states (meaning the state has no associated resolution) have the resolution set to blank. All other bugs will be marked with one of the following resolutions.

• FIXED - A fix for this bug is checked into the tree and tested.
• INVALID - The problem described is not a bug
• WONTFIX - The problem described is a bug which will never be fixed.
• LATER - The problem described is a bug which will not be fixed in this version of the product.
• REMIND - The problem described is a bug which will probably not be fixed in this version of the product, but might still be.
• DUPLICATE - The problem is a duplicate of an existing bug. Marking a bug duplicate requires the bug number of the duplicate and that number will be placed in the bug description.
• WORKSFORME - All attempts at reproducing this bug were futile, reading the code produces no clues as to why this behavior would occur. If more information appears later, please re-assign the bug, for now, file it.

Platform

The platform field is the hardware platform against which the bug was reported. Legal platforms include but are not limited to:

• All (happens on all platform; cross-platform bug)
  
• Macintosh
• PC
• Sun
• HP

Note: Selecting the option "All" does not select bugs assigned against all platforms. It merely selects bugs that occur on all platforms.

Operating System

The operating system field is the operating system against which the bug was reported. Legal operating systems include but are not limited to:

• All (happens on all operating systems; cross-platform bug)
• Windows 95
• Windows 2000
• Mac System 8.0
• Linux
• Other (Not in any of these OSes)
  

Note that the operating system implies the platform, but not always. For example, Linux can run on PC and Macintosh and others.

Priority

The priority field describes the importance and order in which a bug should be fixed. This field is utilized by the programmers/engineers to prioritize their work. The priorities are from P1 (Most important) to P5 (Least important).

Severity

The Severity field describes the impact of a bug.

• Blocker - Blocks development and/or testing work.
  
• Critical - Crashes, loss of data, severe memory leak.
  
• Major - Major loss of function.
  
• Normal - This is the run of the mill bug.
  
• Minor - Minor loss of function, or other problem where an easy workaround is present.
  
• Trivial - Cosmetic problem like misspelled words or misaligned text.
  
• Enhancement - Request for enhancement.
  

To search for bugs associated with an email address:

• Type a portion of an email address into the text field.
• Click the checkbox for the fields of the bug you expect the address will be within.

You can look for up to two different email addresses. If you specify both, then only bugs which match both emails will show up. This is useful to find bugs that were, for example, created by Ralph and assigned to Fred.

You can also use the drop down menus to specify whether you want to match addresses by doing a substring match, by using Regular Expressions, or by exactly matching a fully specified email address.

In this section, you can enter values that are searched for in all the bugs (or whatever you limit the bugs to in other fields). You might want to look at Bugzilla Text Searching to see info on Regular Expressions and text searching. The box next to these fields decides how a match will be determined.

Bug summary

This lets you search the summaries. The summary is one line that attempts to sum up the bug.

A description entry

This lets you search comments. Comments can be added by anybody. Comments are the largest searchable area in most bugs. If you really want to find a lot of matches, search the comments.
Note:Because comments can get quite extensive in bugs, doing this particular type of query can take a long time.

Associated URL

This lets you search the url field. This contains the url of the web page the bug is about.

Status Whiteboard

This lets you search the bug's status whiteboard. The status whiteboard contains general information that engineers add.

Keywords

Name	Description	Bugs

Module options are where you select what program, module and version the bugs you want to find describe. Selecting one or more of the programs, versions, components, or milestones will limit your search.

Products

Although all subprojects within the Mozilla project are similiar, there are several seperate products being developed. Each product has its own components.

Product Description Database Explorer

Version

This is simply the version that the bugs you want to find are marked for. Many of the bugs will be marked for another version and will have their milestones entered instead (milestones explained below).

Component

Each product has components, against which bugs can be filed. Components are parts of the product, and are assigned to a module owner. The following lists components and their associated products:

Component	Product	Description
Data Migration Tool	Database Explorer	Data Migration Tool
DB2	Database Explorer	DB2
GUI	Database Explorer	The database explorer interface
HyperSonicSQL	Database Explorer	HyperSonicSQL
Microsoft SQL Server	Database Explorer	Microsoft SQL Server
MySQL	Database Explorer	MySQL
Oracle	Database Explorer	Oracle
PostGreSQL	Database Explorer	PostGreSQL
Schema Browser	Database Explorer	Schema Browser
Schema Exporter	Database Explorer	Schema Exporter
SQL Editor	Database Explorer	SQL Editor
Webstart	Database Explorer	This refers to a bug in the webstart system.

Milestone

Choosing this section lets you search through bugs that have their target milestones set to certain values. Milestones are kind of like versions. They are specific tentative dates where a massive phasing out of bugs occur and a relatively stable release is produced. For example, Mozilla.org had milestones in the form of "M10" or "M18", but now are in the form of "Mozilla0.9". Bugzilla milestones are in the form of "Bugzilla 2.12", "Bugzilla 2.14", etc.

Inclusion/Exclusion options is a powerful section that gives you the ability to include and exclude bugs based on values you enter.

[Only, Exclude] bugs numbered [text]

This lets you put in a comma-delimited list of bugs you want to have your results chosen from, or those of which you want to exclude. It would be nice in the future if you could type in ranges, i.e. [1-1000] for 1 to 1000. Unfortunately, you cannot do that as of now.

Changed in the last [text] days

Lets you specify how many days ago - at maximum - a bug could have changed state.

At least [text] votes

With this, you can choose how many votes - at minimum - a bug has.

Where the field(s) [fields] changed to [text]

With this, you can specify values to search for in fields that exist in the bug If you choose one or more fields, you have to fill out one of the fields to the right. It might be difficult to figure out what these fields mean if you are a newbie to the query. They match various fields within the bug information. Optionally, you can also enter what value you want the field to have changed to if you only entered one field. For instance, if the bug changed who it was assigned to from jon@netscape.com to brian@netscape.com , you could enter in assigned_to changed to brian@netscape.com.

During dates [text] to [text]

Here, you can choose what dates the fields changed. "Now" can be used as an entry. Other entries should be in mm/dd/yyyy or yyyy-mm-dd format.

The Bugzilla query page is designed to be reasonably easy to use. But, with such ease of use always comes some lack of power. The Advanced Querying section is designed to let you do very powerful queries, but it's not the easiest thing to learn (or explain).

The Advanced Query (or Boolean Chart) starts with a single "term". A term is a combination of two pulldown menus and a text field. You choose items from the menus, specifying:

Field 1: Where to look for the search term
Field 2: How to determine what is a match
Field 3: What the search term is

The real fun starts when you click on the "Or" or "And" buttons. If you push the "Or" button, then you get a second term right under the first one. You can then configure that term, and the result of the query will be anything that matches either of the terms.

You can push the "And" button, and get a new term below the original one - seperated by the word "AND", and now the result of the query will be anything that matches both sets of terms.

You can keep clicking "And" and "Or", and get a page with many terms. "Or" has higher precedence than "And". You can think of the lines of "Or" as having parenthesis around them.

The most subtle thing to notice is the "Add another boolean chart" button. This is almost the same thing as the "And" button. You want to use this when you use one of the fields where several items can be associated with a single bug - including: "Comments", "CC", and all the "changed [something]" entries. If you have multiple terms that all are about one of these fields (such as one comment), it's ambiguous whether they are allowed to be about different instances of that field or about only that one instance. So, to let you have it both ways, they always mean the same instance, unless the terms appear on different charts.

For example: if you search for "priority changed to P5" and "priority changed by person@addr", it will only find bugs where the given person at some time changed the priority to P5. However, if what you really want is to find all bugs where the milestone was changed at some time by the person, and someone (possibly someone else) at some time changed the milestone to P5, then you would put the two terms in two different charts.

So you have gotten all that down, but "What is this junk at the bottom of the form?" You can remember the current query as the default query page that is pulled up whenever you are logged on. There is also an ability to choose how you want your results sorted. When finished, click "Submit".

Written and adapted from some older Bugzilla documents (by Terry Weissman, Tara Hernandez and others) by Brian Bober You can talk to me on irc.mozilla.org - #mozilla, #mozwebtools, #mozillazine, I go by the name netdemon.

Lots of Bugzilla use documention is available through Mozilla.org and other sites:
How To Find Previously Reported Bugs
Bugzilla General Information
Mozilla Bug Report Form
Bugzilla Text Searching
The Bug Reporting Guidelines

My main motive for writing this was to help the engineers by giving new Bugzilla users a way to learn how to use the Bugzilla Query form. I had done a rewrite of query.cgi, so I said, "What the heck, I'll write this too".

You probably looked at the Query page and said, "This page looks too difficult. Now that I think about it, I don't really need to do a query". It is important to make sure that a bug doesn't have a duplicate before submitting it, as is stated clearly in The Bug Reporting Guidelines. The people reading your bugs are busy and usually swamped with bugs. Therefore, you are doing everyone a huge favor to search for a duplicate.

Ok. So lets find a bug! We'll borrow the Mozilla.org database because it's handy.
First, lets make a copy of the query window so you can easily switch between this document and the query.

Do the following:

• Go to the "Status" field in and select all fields (or deselect all fields).
• In Text Search options, put Autoscroll in the summary and Panning in the description entry box (meaning that panning is somewhere in the comments and the bug's summary has Autoscroll in it).

One of the results should have been bug 22775 - [RFE] AutoScroll/Panning support...