Gaia/Email/RequiredBugInfo: Difference between revisions

From MozillaWiki
< Gaia‎ | Email
Jump to navigation Jump to search
No edit summary
(Correct MDN link that was long-dead and provide better windows guidance)
Line 19: Line 19:
** 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:
** 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?  [https://developer.mozilla.org/en-US/Firefox_OS/Firefox_OS_build_prerequisites#Install_adb install adb]
*** no adb?  [https://developer.mozilla.org/en-US/Firefox_OS/Firefox_OS_build_prerequisites#Install_adb install adb]
*** adb doesn't seem to see the device? [https://developer.mozilla.org/en-US/Firefox_OS/Firefox_OS_build_prerequisites#For_Linux.3A_configure_the_udev_rule_for_your_phone enable the permissions in udev rules]
*** adb doesn't seem to see the device and you're using linux and you've checked all the bullet points below? [https://developer.mozilla.org/en-US/Firefox_OS/Firefox_OS_build_prerequisites#For_Linux.3A_configure_the_udev_rule_for_your_phone 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:
** Second: turn on "adb" support on your device and make sure the logcat stays connected even when the screen locks / the display turns off.
*** [https://developer.mozilla.org/en-US/Firefox_OS/Firefox_OS_usage_tips/Remote_debugging "remote debugging" enabled] (which is what makes logcat work at all) from the settings app
*** See https://developer.mozilla.org/en-US/docs/Tools/WebIDE#Connecting_a_Firefox_OS_device which mentions how to go to the settings UI and enable "Remote Debugging" from the "Developer" menu and disabling the screen lock from the "Screen Lock" menu.
*** you need to disable the lock screen in order for logcat to remain connected.
** Capture the logcat!
*** (There are other ways to make this happen, but they are technical and I don't know themFeel free to edit the wiki and include instructions here.)
*** 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, you may not have all of the logic.)
** 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.  
*** 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 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.
**** 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.
*** 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 https://wiki.mozilla.org/Gaia/Email/SecretDebugMode
* 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.
; 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.

Revision as of 11:48, 20 February 2015

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:
    • 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, you may not have all of the logic.)
      • 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 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