From MozillaWiki
< Gaia‎ | Email
Jump to: navigation, search

In order to make it possible to understand, hopefully reproduce, and ideally fix e-mail bugs, it is important that we have a few pieces of information whenever you report a bug:

The type of device in use
(ex: Geeksphone Keon, Geeksphone Peak, Unagi device, etc.)
The "Build Identifier" of the build you are using
(taken from the Settings app under "Device Information", "More Information"), the first 12 digits of the "git commit info" hash that looks like 79e92f6baa09 (taken from the Settings app under "Device Information", "More Information")
Confirm the net connection is working
If the e-mail app is experiencing trouble talking to a server, confirmation that you can use the browser app to access websites from the device *immediately after* the failure in the e-mail app to talk to a server. Sometimes the device is simply experiencing network problems and the e-mail app currently is not smart enough to distinguish between a problem talking to a specific server and a problem talking to any servers.
The e-mail domain you used/are using to create the account
So if you typed in "", please tell us "". If you typed in "", please tell us "".
  • This allows us to try and reproduce any autoconfiguration problems as well as manually investigate DNS entries, etc. It also helps us identify the specific type of mail server in use (Dovecot, Cyrus, etc.)
If this was a problem creating the account, The error code from the account creation failure
A human-readable error string will be displayed in white text on a black background. Below and to the right, the error code will be displayed in brackets. It will be something like "[no-config-info(mx404)]". We want/need the value in brackets.
If this is not a problem creating the account, the account type the e-mail client thinks it is using
This can be accessed by bringing up the settings page for the app, clicking on the account in question, finding the line label "Account type", and reporting the value to the right in blue. The value should be one of "Activesync" or "IMAP+SMTP".
  • The settings menu is accessed by: 1) bringing up the folder list by clicking the three parallel horizontal lines in the top left of the message list card, then 2) clicking on the gear icon in the lower left of the folder list tray.
A log of what was happening around the time the problem happened
This can take the form of the Gecko/GeckoDump/GeckoConsole logcat categories or a log generated by the secret debug mechanism.
  • logcat log of what the e-mail app was doing:
    • Have the "adb" command available and usable. If you can type "adb logcat" with the device plugged in and see some junk show up (especially "LOG: Mail universe/bridge created, notifying" when you start the e-mail app from when it was closed), then it's working! No adb? Not working? then:
    • Second: turn on "adb" support on your device and make sure the logcat stays connected even when the screen locks / the display turns off.
    • Capture the logcat!
      • It is very important that you capture the logcat to a file and that you start the capture process before reproducing the bug. (logcat uses a circular buffer that discards older entries when the buffer fills up, so if you run logcat only after the problem happens, we may miss out on important information.)
      • Running logcat:
        • Want to see the log as it happens and you are using linux or OS X?
          • Run adb logcat -v time -s GeckoDump:V Gecko:V GeckoConsole:V OomLogger:V | tee FILENAME-TO-LOG-TO. Please start running this command BEFORE you attempt to reproduce the problem. Once you are done, hit control-C and send us the file.
        • Using windows or that gave you an error about the command "tee" not existing? Use file redirection:
          • Run adb logcat -v time -s GeckoDump:V Gecko:V GeckoConsole:V OomLogger:V > FILENAME-TO-LOG-TO. Please start running this command BEFORE you attempt to reproduce the problem. Once you are done, hit control-C and send us the file.
      • (What did all those cool flags do?)
        • The logcat arguments filter out a lot of the noise that we don't care about and gives us timestamps.
        • The "tee" command lets you see the output while also logging the output directly to a file. This way you don't have to copy and paste the log.
      • Make sure the log file does not include any private information / redact any private information
        • The email app tries hard to avoid including private information, but the log may contain activity from other apps. Specifically, the email app may include:
          • Your email address (if creating a new account)
          • The domain of the mail server you use (anytime we connect to a server, and especially during creating a new account)
        • It's okay to edit the file, including using search-and-replace to change domain names or stuff like that. If you remove some lines entirely, it can be helpful to make sure you tell us that, possibly by writing in the log what was removed.
  • Secret debug: For now, logcats are usually still good enough, but if we request or you would like to provide the more detailed structured logging output, please see
If the problem involves a specific message and the problem is not duplicated for other messages, it would be great if you could look at the message in an alternate mail client
(like webmail or Thunderbird) and see if the message has anything special about it. If you can't tell and the message is not private, attaching a copy of the message to the bug can be very helpful.

Setting the dump() preference

This hopefully isn't needed anymore. I think this is all out of date if it is.

Thanks to Dave Hylands for steps here:

Step 1:
PREFS_JS=$(adb shell echo -n "/data/b2g/mozilla/*.default")/prefs.js
adb pull $PREFS_JS
vi prefs.js

Step 2: add line where there is the other user_pref lines: 
user_pref("browser.dom.window.dump.enabled", true);

Step 3:
adb shell stop b2g
adb push prefs.js $PREFS_JS
adb shell start b2g