While filing a bug for a crash you have encountered or found using crash stats, there are a few rules you can follow which will help developers to efficiently debug the problem and find a fix. If you're unfamiliar with how to use Bugzilla in general, you can watch this helpful video.

Example walkthrough

Let's use bug 1074196 as an example again. As mentioned at the start of the first comment on the bug, it was filed from this crash report. This crash report expires six months after it was submitted and some info is only shown for a shorter time, so you might not see the same information.

The lower section of the report has the crash stack with a header of "Crashing Thread". The right-hand column of this table has the file names that link to the actual code. For example clicking the first one there goes to line 228 of nsUrlClassifierPrefixSet.cpp, I click the "gpascutto@197683" link on the left next to the code line 228, which links to the actual code changes that a person with the (nick) name of gpascutto did in the changeset no. 197683 of our code. From there, I click again on the link "9d24ecc84a50" (that is a random identifier for this changeset) next to "changeset 197683". That makes me see the actual comment that gpascutto made for this changeset, in this case, "Bug 1046038 - Replace linear prefix array by array of arrays. r=mmc". Finally, I can click on the bug linked there and look at their data, like product and component.

This action takes multiple clicks.  There are ideas on how to improve it, but for now, this series of clicks is necessary.

After following those steps, I find the product "Toolkit", component "Phishing Protection", so in the crash report, I clicked the "Toolkit" link next to "Report this bug in" within the Bugzilla section in about the middle of the page when scrolling down. Back on the crash report, I go to the top and click the "More Reports" link to get to a signature summary page to get more info about those crashes.

Looking through those, I try to find properties that are out of the ordinary. For example, only a few Product versions being listed in the "Products" section, only very specific OSs listed, or specific graphics adapters, or much fewer installations than crashes listed in "Crashes per Install"). Looking at the list in the "Reports" tab, some things like the same address on all reports are interesting as well. List all of those things in a comment on the bug report. Posting a link to the "More Reports" page is usually an excellent idea as well.

Explaining the entire hierarchy is not possible.  It changes all the time because components are added and retired all the time. However, I can give you a few pointers. All of this has grown organically over the 15+ years that the Mozilla project and Bugzilla have existed. Things would be different if we were designing it from scratch.

Understanding the Bugzilla hierarchy

The most important pieces:

  1. There are Bugzilla "products" for the major Mozilla products such as Firefox, Firefox for Android, Firefox OS, Thunderbird, SeaMonkey. Those "products" *only* cover code that is unique to each product. They do not cover shared code that is present in multiple products.
  2. For shared code, there's the "Core" product and the "Toolkit".  The "Core" has all the underpinnings of Gecko and "the Mozilla platform", like Graphics, JavaScript Engine, and networking. The "Toolkit" for some other common code that is closer to or including user interface pieces, like Add-ons Manager, and some other pieces. The difference between those parts is fluid, and many of us often do not know which is which; you have to search and learn here.
  3. There are many supporting "products" like for websites and server software, legal issues, localizations, IT operations, and third-party plugins. You can ignore them most of the time, but sometimes you might get directed to one for something. Best is not to try to understand more of those than what you run across and need for a certain task.
  4. All those "products" in Bugzilla have "components" underneath them. While filing a bug in Bugzilla, once you have selected a product, a description of the component is displayed when you choose one from the list. Try to use your best guess from those descriptions of where your bugs fit. It is easy to change afterwards, and we put bugs into "wrong" components all the time as well as for some things that are just hard to figure out or whose lines are blurry. Don't shy away from setting one; it is easy to move to a different one afterwards if you guess wrong.

The general rule here like with many other things in our community is: guess and try to do what makes the most sense for you, nobody will think less of you if you guess wrong. Be bold and try what sounds right, and learn as you go. It is better to try and learn than not to try in the first place.