Gaia/Email/RequiredBugInfo

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 "foo@gmail.com", please tell us "gmail.com". If you typed in "foo@vanitydomain.com", please tell us "vanitydomain.com".

• 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:
    • no adb? install adb
    • adb doesn't seem to see the device? enable the permissions in udev rules
  • Second: make sure the logcat stays connected even when the screen locks / the display turns off. You have to have both:
    • "remote debugging" enabled (which is what makes logcat work at all) from the settings app
    • you need to disable the lock screen in order for logcat to remain connected.
    • (There are other ways to make this happen, but they are technical and I don't know them. Feel free to edit the wiki and include instructions here.)
  • Please provide the logcat by running 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. logcat uses a circular buffer that discards older entries when the buffer fills up, so if you run logcat only after the problem happens, you may not have all of the logic. Once you are done, hit control-C and send us the file.
    • • 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.
      • Also, please only include portions of the log from the e-mail app; searching for "LOG: Mail universe/bridge created" is a good way to find out when the e-mail app started. Apparently, other apps are much more likely to reveal private data, and we do not want any of that. We do try to avoid doing that, but please also skim the contents of the log to make sure there are no obvious reveals of personal information. Currently, we expect the e-mail domain you are signing up for to be exposed in the log if your problem occurs during the configuration process, but we really need that info anyways.
• 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 https://wiki.mozilla.org/Gaia/Email/SecretDebugMode

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