For the latest UX specifications, please visit: https://mozilla.box.com/applications
Gaia/Email/UX/Decisions - Notable UX Decisions and rationales
- new building blocks page
- old building blocks page, fairly broken
- Things you can look at but are not canonical; these are inputs to the building blocks / UX process:
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.
- Gaia/Email/Implementation/Limits: Maximum sizes of things, stuff like that.
- Gaia/Email/Implementation/MailSynchronization: General sync strategy, how we sync IMAP, and how we sync ActiveSync. Sadly, these are very different things because they are very different protocols.
- Gaia/Email/Implementation/MessageDisplayAndAttachments: Plaintext mail, HTML mail, quoting, attachments!
- Gaia/Email/Implementation/FakeServers: Fake IMAP and ActiveSync servers for testing purposes.
- Gaia/Email/Standards/PushNotifications: We want to try and get IMAP servers to support our WebAPI/SimplePush API, which just means being able to PUT/POST a small amount of data to a URL.
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)
- Gaia/Email/HistoricalReqs: Historial requirements and use cases that are misleading to keep on this page.
The security review of this app can be found here.