799822 - [email/IMAP] Save e-mail drafts in drafts folder / support drafts-on-server

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::E-Mail, defect, P5)

Description

[Andrew Sutherland [:asuth] (he/him)]

This is a migration of part of https://github.com/mozilla-b2g/gaia/issues/2482.

MailAPI supports draft saving, but the back-end is not implemented.  This is the IMAP piece.  Bug 796674 is the ActiveSync piece.

Comment 1

[Casey Yee]

It has been agreed that this will be a V2 feature.  

For v1, If the user closes the compose email screen the email app should prompts "Discard message" y/n

Comment 2

[ayman maat :maat]

as outlined in bug 796674 this simply cannot be a V2 feature. I will repeat here:

For a UX PoV the ability for the end user to save an email as draft is an integral and ubiquitous part of the email usage experience. This is especially the case when there is a 'Drafts' folder contained within the draw that is presented under the 'folder' icon, which is the case when all email accounts i have tested with are synced.

Bottom line is that end user expectation is set and fossilized that emails can be saved to draft by previous long term interaction with their email accounts on other platforms. We also reinforce that expectation by allowing a drafts folder to be created upon sync. We simply cannot have a viable launch for the email app without this functionality

I am going to raise this as a UX P1. 

putting Josh on CC to take this bug into tirage asap.

Comment 3

[Josh Carpenter [:jcarpenter]]

This bug was included in the list of UX "must fix" bugs delivered to stakeholders on 12/20, as determined by the Moz+TEF UX teams. There has been no movement since then. With everyone returning from holidays later this week we will checking in with Product and Engineering to determine whether this is addressable for v1.

Comment 4

[Josh Carpenter [:jcarpenter]]

This bug was included in the list of UX "must fix" bugs delivered to stakeholders on 12/20, as determined by the Moz+TEF UX teams. There has been no movement since then. With everyone returning from holidays later this week we will be checking in with Product and Engineering teams to determine whether this is addressable for v1.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

For product consideration purposes, there are really 2 levels of implementation possible:

1) Local-only drafts.  Do not attempt to persist them to the server, do not let the user resume editing a draft from the server.  We would probably want to create a fake folder called "Local drafts" and stash things in there.

2) Full-on, server-persisted drafts.  The primary complexities that arise from this are:
a) It is possible for drafts to be in a state where they are locally known to us but not uploaded to the server because the device is offline or otherwise unable to talk to the server.  This implies speculative headers similar, but not identical, to what we do for moves.  (This may require UX to define some type of visual affordance so the user can know the message has not yet hit the server.)  This entails additional code to link the operation to the speculative header so that we can cancel the APPEND operation for messages if successive draft revisions occur or if the user decides to delete the message.  (This is strongly mandated by privacy concerns.)
b) We have not yet implemented an IMAP APPEND type operation for ActiveSync.
c) We will need to parse drafts authored by other clients for use by our compose process.  There will be complications with HTML-formatted e-mails.  Currently, for v1 we only support plaintext composition and our HTML support is limited to reply/forward cases where we put the existing HTML in an immutable region below our textarea.  If there is a text/plain variant, we will have the option to destructively favor that, but regardless we will need to handle text/html compose parts.  The most obvious solution is to detect messages from our own client and suck out our text part and cram the rest into the immutable HTML bit.  If we didn't author the message, we would cram the entire thing in the HTML bit, which could be very awkward for the user since anything they previously typed will be inaccessible.  Round-tripping messages authored by other clients may be brutal on the message since we must sanitize the HTML.


If UX wants auto-save functionality, there will be additional complexity for either solution.  Either way, UX should define the actual flow for resuming composition of an existing message and deleting a draft.  (Co-opting the default action of single click on a message to resume composition makes single-message deletion unavailable.)


I think option #2 is nuts given current deadlines and the number of new or existing-but-lightly-tested moving parts involved.  Option #1 is not completely infeasible.

Comment 6

[Josh Carpenter [:jcarpenter]]

Thanks for the breakdown, Andrew. Much appreciated. I'm talking w/ CLee about this and will follow up!

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

Useful excerpts from one of my messages to dev-b2g (Re: [b2g] IndexedDB Blob storage versus DeviceStorage Blob storage, managed versus unmanaged?):

===
The draft currently is only saved locally.  It's in the backlog to also save the draft on the server, but there are real-world complexities that mean there are 4 distinct cases, most of which (by volume) we can't do this for:

- on IMAP servers with the CATENATE and URLAUTH extension accompanied by an SMTP server with BURL extension support we can both (CATENATE) update/replace a draft without re-uploading the attachments and send the message from the IMAP server (we use BURL to tell the SMTP server to suck the message or pieces of it out of the IMAP server via URLAUTH).  In the future, IMAP SUBMIT will become the way to do this, but it's still an in-progress draft (http://datatracker.ietf.org/doc/draft-kundrat-imap-submit/).  I am not aware of any servers supporting this, though I'm sure they exist somewhere.  (Dovecot 2.2+ supports URLAUTH, but postfix, a popular choice, does not support BURL).

- on IMAP servers with only the CATENATE extension or no BURL support on the SMTP server despite URLAUTH IMAP support, we can keep the draft up-to-date with the attachments, but sending the message is still a completely separate upload so we have to keep the attachments around locally (unless we re-download them right before sending, which seems bad).  We would probably upload the attachments to the server for those servers for which the act of sending the message via SMTP does not automatically place the message into the sent folder since we would end up doing a duplicate APPEND into Sent anyways.  This works on modern releases of IMAP servers like Dovecot (2.2+), Zimbra (used on mozilla.com) and Cyrus (used on fastmail.fm).

- on IMAP servers without CATENATE we have to APPEND the message from scratch to the server every time the draft get edited.  For these servers I don't think we will ever upload the attachments by default, at least not until we have the ability to detect we are on an unmetered high-bandwidth connection.  This is the case for GMail, Yahoo, all domains hosted by dreamhost.com, all domains hosted by godaddy.com, etc.

- on ActiveSync servers the protocol has no support for sticking stuff in a drafts folder.  We can never upload drafts ever. 
====

Comment 8

[Dylan Oliver [:doliver]]

triage: feature request, not blocking for 1.2

Comment 11

[BMO Automation]

Firefox OS is not being worked on