This article provides a guide to filing bugs against the Firefox OS project, including Gaia and B2G.
As with most projects in Mozilla, we use Bugzilla for bug and issue status tracking. You can file bugs to bugzilla when you found bugs — we have a separate product for Firefox OS, which contains components for topics falling under Gaia, Gonk and Gecko. You should use this component to file bugs against Firefox OS, Gaia, etc.
To file an effective bug, you can use this Bugzilla template and follow the instructions below to fill out the template.
Mandatory and optional fields
When filing a new bug, some fields are mandatory:
|Component||Choose the category the bug should belong to. If you have no idea which category the issue should be, You can put it in "General".|
|Summary||Give a summary to briefly describe the bug.|
|Description||Describe the situation clearly. A good bug should contain the Steps to reproduce (STR), Expected Results and Actual Results. Please also mention the Reproduction Frequency (i.e. how many times the bug appears if you repeat the steps over and over).|
|Build Information||Go to Settings > Device Information > More Information and mention the following in the bug: OS Version, Build Number, Platform Version, Build Identifier, Update Channel and Git Commit Info. (If you have a Mac/Linux computer with adb and git installed, you can run this script and paste the output of the script in the bug.)|
|Screenshots||Please attach a screenshot that can help us analyze the bug. (On the Flame device, hold down the Power button and Volume Down button simultaneously for 2 seconds till the phone shows a screenshot notification. Then transfer the screenshot image to your computer via USB.)|
|Video||If your bug involves screen transitions that are difficult to capture via screenshots, please shoot a video. You can upload the file as an attachment to the bug. You can also upload the video to YouTube and copy-paste its URL.|
|ADB logs||If your computer has adb installed, please connect it to your phone and run the command |adb logcat|. Please put the output of this command into a plain text file and attach it to the bug.|
The following fields are optional:
|Depends/Block||Show the dependency between bugs.|
|Keywords||Keywords for bugzilla. Specific groups will use it for tracking.|
|Whiteboard||Contains tags. Add any tag to it for tracking. You shouldn't remove others' tags without permission.|
|See Also||Sometimes, two issues are related and you can specify this here.|
|Flags||Flags for tracking status; the most used flag in Firefox OS bugs is blocking-b2g. If a bug is set as blocking-b2g, it means we should pay more attention to it as it threatens to block a release.|
|Security||If a bug is related to personal data security, loss of earnings, and other such issues, you should check the checkbox and it will only be visiable to involved employees.|
To find more information on bugzilla fields, you can view the Bugzilla Fields page on Bugzilla.
The following table provide information on common keywords you'll see used in Firefox OS bugs.
You should always indicate the build/OS/platform(s) used to verify the bug in the bug comments, before you change the Status to Verified. If the bug is reported on all three platforms and you only have one platform to verify the fix on, go ahead and do so and note it in the bug, but do not mark the bug as Verified. All platforms must be checked before moving Status to Verified.
Finally, if other bugs have been marked as a duplicate of the bug you're verifying, be sure to check and mention those as well. Often developers mark related — but not identical — bugs as duplicates, and these can be overlooked if not checked.
|meta||Indicates that the bug is a status tracking bug. Mozilla uses this tag to tracking multiple bug or user story implementation statuses. Once marked like this, developers should not land patches on top of such bugs. Please be reminded that project managers and QA staff will use meta bugs for tracking.|
|qablocker||Use this keyword for bugs that are blocking testing (manual or automated testing of a feature) and need to be fixed by the next Beta or RC milestone.|
|qawanted||Use this keyword for bugs that need more info, require reproducing or testcasing, or are duplicates (but you can't find the original bug being duplicated). Required QA work progress is recorded in the whiteboard; you should remove this keyword when the required QA work has been completed.|
|regression||This keyword means that the problem was fixed, but then it came back (regressed) and the bug in question is a new bug, filed to track the regression. It can also refer to problems outside those identified in pre-check in and smoke tests, which were found in current builds and that were known to be working in previous builds. Tracking these bugs helps us to identify areas that are fragile, prone to breakage and are good candidates for adding to smoke and pre-check in tests.|
|regressionwindow-wanted||Indicates that the bug is a regression, and would strongly benefit from someone identifying the time period in which it happened, ideally to a specific check in.|
|steps-wanted||Highlights a bug that would greatly benefit from someone identifying the steps to reproduce it.|
|verifyme||Means that this bug is ok to verify with the latest FX OS build by someone other than the QA Contact indicated. The bug has specific machine configuration details indicated for verifying the fix. You should try to reproduce the failure, and, if you agree that the resolution of Fixed is correct, mark the Status as Verified.
|crash||Add this keyword if you encounter a crash in FX OS.|
Note: You can additionally refer to Bug writing guidelines. The Mozilla B2G QA Wiki page also has some useful resources on handling Firefox OS bugs; the most useful pages are Bugzilla Usage and Incoming bug triage for Firefox OS.
Note: For more information on handling bugs during Gaia development, read Submitting a Gaia patch.