: New feature! You can now create or update wiki pages by importing directly from etherpad. Learn how and give it a try.


From MozillaWiki
< B2G‎ | QA
Jump to: navigation, search

Intro to Bugzilla

Tips and Tricks:

Before Filing

Check for Dups

  • Verify that there isn't a bug on it first
    • Sometimes searching for the bug isn't easy. There's many ways to say what a bug is or how a bug is affected. Getting used to some of the terminology helps out greatly.


One way to do searching:

  • Go to : the search page
  • Under Classification, select the Client Software
  • Under Product, select Firefox OS
  • Select the appropriate Status/Resolution in terms of your search
    • Optional:
    • select Search by Change history
    • place in the appropriate time of your search
  • select Custom Search
    • change the drop down to "Summary" or "Comment" or whatever you are searching for, change the middle to "contains the string" and in the text field type in your query
    • add and/or logic based on your search


  1. If the Summary contains the appname, it makes it that much easier to search for that specific app
  2. People may use different terminology for the same meaning : ie VKB, SKB,Virtual Keyboard, Soft Keyboard,
  3. If the bug happens in a specific component that you are aware of, select that component ie if the bug happens in FMRadio, select Component FMRadio.

Common Queries

  • B2G Bugs filed today:

Bugs Filed Today

Know your audience

  • who is your audience?
  1. developers : Make it easy for the developers to understand how to reproduce the bug; they are the ones fixing the bug you find!
  2. other qa : Make it easy for the other QA to reproduce your issue to verify if it's fixed or not
  3. PMs/EPMs/Releng Managers : They need to understand how critical the bug is to place fixing the bug in the schedule

Creating a bug


  • The product should be Firefox OS
  • The Components depend on where the failure occurs:
    • if it's a driver issue (gonk level), then it's most likely should be placed in the Vendcom
    • if the bug happens in a core app such as email, then it should be placed in that component
    • We are trying to stay away from using General; having said that if you cannot figure which component it should go in please use that as the last case scenario.
  • We do suggest that you use other Firefox products such as Firefox for Android or Firefox Desktop to see if you can reproduce the bug. If it happens in other products, chances are it's a Gecko level bug.


Have a clear title

  • be precise
    • A title of a bug should describe the issue clearly and a reader can tell what the bug is by just the title alone; this helps with triaging the bug
  • What, Where, When, Why, How are some questions that should be answered in the title.


Please list the Build you are using including the gecko /gaia pull as well as the device you are using.

You can use : https://github.com/Mozilla-TWQA/B2G-flash-tool/blob/master/check_versions.sh in order to capture some of these details.


Gaia      d65d0f7fa9cda0a41b98149e3c540a41eb27b11f
Gecko     https://hg.mozilla.org/integration/b2g-inbound/rev/9a0b874c531b
BuildID   20140327113532
Version   31.0a1
ro.build.date=Mon Dec 23 16:36:04 CST 2013
Alcatel Open Fire


  • please be clear in the STRs; having a step by step of how you produce the issue makes it clear and concise on how you were able to hit the bug.
    • This allows the developer to reproduce how you got there and where the issue may lie.

Expected Results

  • What you would expect from the steps provided.
    • sometimes knowing what's expected helps the developer, because what you may expect might not be what was designed for the feature.

Actual Results

  • The result from your Steps to reproduce.


  • Template
Summary: [<appname/Area>] :

## Environment :
<phone version>, <build id> <gaia timestamp>
## Repro :

## Expected :

## Actual :

## Note :
  • Example:

see bug 804883, bug 797140 for examples.


When creating a bug, be sure to add any information that will help

  • any logs / logcat
  • crash reports
  • OOM (adb shell dmesg)
  • any screenshots
  • any images
  • any videos
  • any other information/attachments

Other important items to fill

  • Whiteboard tags:
    • [b2g-desktop-builds] : for desktop builds
    • regression
    • [b2g-crash] : a crash that happens in b2g (note bugs could move to core if it is found to be a gecko crasher so it makes it easier to track crashing bugs this way.
  • Keyword tags:
    • qawanted : bugs that need QA to help provide more information
    • polish : when it's a fixing/cleaning up the look and feel; it may not necessarily be blocking
    • steps-wanted : need repro steps
    • crash : a crashing bug
    • hang : hanging bug
    • Other keywords
  • Flags:
    • Blocking-name of release ?
      • ex 1.3?; 1.4?; 1.5?
    • status-b2g-v(version)
      • which version(s) the bug is affecting such as status-b2g-v1.3: affected
  • Crashes:
    • if you crashed, having the crash id helps. Please try to get that information from :
  adb shell ls -l /data/b2g/mozilla/Crash\ Reports/submitted/

Filed a Bug? There's more things to do!

  • check if it's a regression
    • If it is a regression; tag it with the keywords: "regression" and "regressionwindow-wanted"
      • find out the regression range and remove the regressionwindow-wanted.
  • If it's a crash in b2g, whiteboard the bug "[crash-b2g]" keyword the bug "crash"
  • If it's a SUMO bug, whiteboard the bug "[SUMO-b2g]"
  • If it's a Gaia UI automation test was disabled because of a bug, whiteboard tag "xfail"


Advanced Info




Other information on B2G/Gaia