This section distills some Bugzilla tips and best practices that have been developed.
Bugzilla comments are plain text - so typing <U> will produce less-than, U, greater-than rather than underlined text. However, Bugzilla will automatically make hyperlinks out of certain sorts of text in comments. For example, the text "http://www.bugzilla.org" will be turned into a link: http://www.bugzilla.org. Other strings which get linkified in the obvious manner are:
| bug 12345 |
| comment 7 |
| bug 23456, comment 53 |
| attachment 4321 |
| mailto:george@example.com |
| george@example.com |
| ftp://ftp.mozilla.org |
| Most other sorts of URL |
A corollary here is that if you type a bug number in a comment, you should put the word "bug" before it, so it gets autolinkified for the convenience of others.
Quicksearch is a single-text-box query tool which uses metacharacters to indicate what is to be searched. For example, typing "foo|bar" into Quicksearch would search for "foo" or "bar" in the summary and status whiteboard of a bug; adding ":BazProduct" would search only in that product. You can use it to find a bug by its number or its alias, too.
You'll find the Quicksearch box in Bugzilla's footer area. On Bugzilla's front page, there is an additional Help link which details how to use it.
If you are changing the fields on a bug, only comment if either you have something pertinent to say, or Bugzilla requires it. Otherwise, you may spam people unnecessarily with bug mail. To take an example: a user can set up their account to filter out messages where someone just adds themselves to the CC field of a bug (which happens a lot.) If you come along, add yourself to the CC field, and add a comment saying "Adding self to CC", then that person gets a pointless piece of mail they would otherwise have avoided.
Don't use sigs in comments. Signing your name ("Bill") is acceptable, if you do it out of habit, but full mail/news-style four line ASCII art creations are not.
Use attachments, rather than comments, for large chunks of ASCII data, such as trace, debugging output files, or log files. That way, it doesn't bloat the bug for everyone who wants to read it, and cause people to receive fat, useless mails.
Trim screenshots. There's no need to show the whole screen if you are pointing out a single-pixel problem.
Don't attach simple test cases (e.g. one HTML file, one CSS file and an image) as a ZIP file. Instead, upload them in reverse order and edit the referring file so that they point to the attached files. This way, the test case works immediately out of the bug.
Bugzilla stores and uses a Content-Type for each attachment (e.g. text/html). To download an attachment as a different Content-Type (e.g. application/xhtml+xml), you can override this using a 'content-type' parameter on the URL, e.g. &content-type=text/plain.
If you have a really large attachment, something that does not need to be recorded forever (as most attachments are), you can mark your attachment as a Big File, Assuming the administrator of the installation has enabled this feature. Big Files are stored directly on disk instead of in the database, and can be deleted when it is no longer needed. The maximum size of a Big File is normally larger than the maximum size of a regular attachment.
On the "Dependency tree" page linked from each bug page, you can see the dependency relationship from the bug as a tree structure.
You can change how much depth to show, and you can hide resolved bugs from this page. You can also collaps/expand dependencies for each bug on the tree view, using the [-]/[+] buttons that appear before its summary. This option is not available for terminal bugs in the tree (that don't have further dependencies).