I’m pleased to announce that this Friday, June 10th, 2011, Mozilla QA is organizing a testday for the newest developer tool for the open web: Scratchpad. If you do any development work whatsoever, we need your help testing and want your feedback on this tool.
Please join us at any time between 2am and 5pm Pacific Time this Friday.
If you run Firefox Beta or Firefox nightlies, you will probably run into some issues. Reporting these bugs and crashes will help us to make sure the user experience is better for all Firefox 4 users.
Marcia Knous is part of the Firefox QA team. Because reporting a good bug is not that easy but extremely important, Marcia explains us how to file a bug correctly:
Starting out with bugzilla
So you found a bug – To make sure this bug will be considered, you need to create an entry into our bug database: bugzilla. And as a good first step into Bugzilla, I strongly suggest you start by watching this video:
You can also use the Bugzilla Guided Tour which is a step by step Guide to filing a bug.
Reporting a bug
After you have a better grasp of how to file a bug, it’s time to gather the data we will need to enter the bug into Bugzilla.
As we are web developers, experimenting with pre-release of Firefox and experimenting with new standards, you can be faced with crashes and incorrect behavior.
Although you may not find it, this will at least try to prevent duplicate bugs from being filed. Also consult the Bugs filed Today link to see if someone beat you to it! You can also add ”’DUPEME”’ to the status whiteboard if you are unsure, and a query will pick that up so we can check to see if it a dupe.
It’s a crash? Go get the Crash Information
We are keeping a stack trace of crashes. You can see these traces
if you type “about:crashes” in the URL bar
Locate the crash stack – the latest one is the first of the list – it will look something like [@ libgcrypt.11.dylib@0xc21a ].
Add it in that exact form in the Summary field. An example would be: Crash in [@ libgcrypt.11.dylib@0xc21a ] while loading Zimbra calendar.
Paste the report ID link in the Bug Summary section. (This is important so the crash shows up in crash-stats.mozilla.com with a bug associated to it). A report ID will look like this: bp-68a686c4-9a15-4326-a812-c8b772100812
Have a Layout bug or Reproducible Crash? Add a Testcase
As you can imagine, it’s way easier to work on a bug with a testcase.
You can attach the testcase under the attachment section. And in this case, add the “testcase” keyword to the bug
Make the Bug Summary useful
Which version of Firefox do you run? To know that, we
need the “Build ID”. Click “help” then “about Firefox/Minefield”.
It should look like this:
Mozilla/5.0 (X11; Linux i686; rv:2.0b4pre) Gecko/20100817 Minefield/4.0b4pre
Also, include a set of Steps to Reproduce the bug. Please be as detailed as possible. For example, you should include whether you used the mouse or keyboard to initiate a command. Mozilla Developer Bug Writing Guidelines has many other suggestions as to what you should include in the bug.
These Bug Guidelines will take you through a tour of some of the other information that needs to be included, such as Product, Component, Version, Hardware/OS, and Keywords.
(Tip: As a web developer, you probably want to open a bug into the Product “Core”. Then, choose the Component depending on the bug.)
Thank you!!!
We know how difficult it can be to open a bug. Opening a bug is extremely useful. So thank you so much to taking the time to make Firefox better!
