834671 - [EMAIL] Sent email folder does not update with the sent email if the user launches compose email and sends the email whilst viewing the sent folder

Status: RESOLVED WONTFIX

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

Description

[ayman maat :maat]

**DESCRIPTION**
[EMAIL] Sent email folder does not update with the sent email if the user launches compose email and sends the email whilst viewing the sent folder, therefore the user has no confirmation that the email has been sent

**PATH**
1) open email app
2) navigate to sent email folder
3) launch email composer
4) compose email
5) press send

**EXPECTED**
a) email composer closes
b) sending message spinner informs of sending process
c) sending message spinner closes and end user is presented with sent mail folder containing the sent email

**ACTUAL**
a) email composer closes
b) sending message spinner informs of sending process
c) sending message spinner closes HOWEVER end user is presented with sent mail folder WITHOUT the least sent email
...user must press refresh to see newly sent email in email folder


[TEF_REQ] as Feature required for TEF build.

Comment 1

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

We've got 3 code paths for sending:

1) ActiveSync.  Send automatically puts the message in the sent folder.  We do not speculatively put a header in the offline folder.

2) IMAP non-gmail.  SMTP does not put the message in the sent folder automatically, we manually issue an APPEND into the sent folder, but we don't generate an offline header for it.

3) IMAP gmail.  SMTP does put the message in the sent folder automatically, so we do not issue an APPEND.  We do not generate an offline header.


The general set of solutions are:

A) Trigger refreshes of the sent folder for an account after we send the message via resetAndRefreshActiveSlices.  This is the simplest.

B) Refresh for ActiveSync/gmail IMAP, add speculative offline headers for non-gmail IMAP.  In the ActiveSync and gmail IMAP cases we are at a disadvantage for mapping the newly synced headers to the offline headers because we can't predict the timestamps that will be associated with the message and we are not provided with any GUID/UID information.  This implies requiring the creation of a filtering step for the new messages to try and match them up with our offline headers efficiently.  Although for gmail IMAP we could just let the system purge and re-download the message.  For non-gmail IMAP it's almost easy because we control the APPEND date; the problem is that yahoo's IMAP server may still have a broken APPEND implementation, but that's a major spec violation on their part, and our IMAP logic will recover from that.

C) Offline headers for everyone.  Do the hard stuff alluded to in B.


Since we currently require the e-mail client to be online to send messages, option A sounds like a pretty appealing solution.

Comment 2

[BMO Automation]

Firefox OS is not being worked on