: Etherpad users! We are developing an extension that will allow you to create pages from etherpads quickly and easily. Please visit our sandbox and help us test it.


From MozillaWiki
Jump to: navigation, search

Design Specs


For the latest UX specifications, please visit: https://mozilla.box.com/applications

Gaia/Email/UX/Decisions - Notable UX Decisions and rationales



The e-mail app consists of a back-end which is developed in https://github.com/mozilla-b2g/gaia-email-libs-and-more and a front-end which is developed as part of Gaia at https://github.com/mozilla-b2g/gaia/tree/master/apps/email. The intent of separating the library from the UI is to make the back-end reusable. The primary motivation is to allow a keyboard-friendly desktop UI to be developed against the library without trying to have a single UI trying to meet two radically different use cases.

To re-cap, check out these projects / repositories:


See Gaia/Email/Features for a partial list of things we currently support or don't support.


The following pages are an attempt to describe how the e-mail implementation works without requiring you to read the block comments in the source code in order to understand. The goal is to provide context of the e-mail problem domain and our approach to dealing with it. We are not going to go into low-level details because those can change frequently, but we will try to strike a balance by linking to the source code and its block comments.

Standardization Efforts

QA / Filing Bugs

Bugs should be filed in bugzilla.mozilla.org under the "Boot2Gecko" product and "E-Mail" component. When filing a bug, be sure to provide the details requested in Gaia/Email/RequiredBugInfo. It's preferred if you do a search within the component first to look for any bugs that might already be filed on the problem. Unfortunately, there are still a lot of known bugs :(

Resources on how to provide information for bugs:

  • Gaia/Email/RequiredBugInfo: What we need to be able to properly investigate a bug.
  • Gaia/Email/ProvidingEmailsForDebugging: How to provide problematic e-mails so developers can directly reproduce problems. You can either attach the e-mails as attachments to the bug or e-mail them directly to the developers working on the bug if you are somewhat concerned about the world seeing any of the information in the e-mail (but not concerned enough that you have a problem providing it to a developer.)
  • Gaia/Email/DebuggingTricks: Trying to help reproduce a problem? Here are some tricks you can use to make your life easier.


  • Front-End Tests
    • live in the gaia repo
    • Tests by default run against
  • Back-End Tests
    • live in the gaia-email-libs-and-more repo (aka GELAM). For info on the tests in general, see: Gaia/Email/LoggestTestFramework
    • run against JS implemented fake-servers by default, but can be run against real servers as well.
    • contain a mixture of test types:
      • unit tests. examples: test_intl_unit.js (simple), test_folder_storage.js (complex)
      • higher level tests. ex: test_imap_general.js
      • end-to-end-ish tests. ex: test_compose.js (creates a message with an attachment, sends mail to itself, checks the messages and the attachment, sends a reply, etc.)


(or rather, dependencies with wiki pages that tell you stuff)


Sprint Demos

Coming soon.


Security Review

The security review of this app can be found here.