This section distills some Bugzilla tips and best practices that have been developed.
Bugzilla comments are plain text - so posting HTML will result in literal HTML tags rather than being interpreted by a browser. However, Bugzilla will automatically make hyperlinks out of certain sorts of text in comments. For example, the text https://www.bugzilla.org will be turned into https://www.bugzilla.org. Other strings which get linkified in the obvious manner are:
| bug 12345 |
| bug 23456, comment 53 |
| attachment 4321 |
| mailto:[email protected] |
| [email protected] |
| 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'll find the Quicksearch box on Bugzilla's front page, along with a 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, particularly 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.
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.
Try to make sure that everything said in the summary is also said in the first comment. Summaries are often updated and this will ensure your original information is easily accessible.
You do not need to put "any" or similar strings in the URL field. If there is no specific URL associated with the bug, leave this field blank.
If you feel a bug you filed was incorrectly marked as a DUPLICATE of another, please question it in your bug, not the bug it was duped to. Feel free to CC the person who duped it if they are not already CCed.