834774 - [EMAIL] No offline mail sending / no concept of an 'Outbox' in the current email app

Status: RESOLVED DUPLICATE of bug 921050

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

Description

[ayman maat :maat]

There is no concept of an 'Outbox' in the current email app. This means that if the user tries to send an email and there is no network connection they are simply presented with a message that states 'Sending email failed'... There is no facility to 'queue up' composed emails to be sent as soon as network coverage is restored.

The concept of an Outbox that provides a facility to 'queue up' composed emails to be sent as soon as network coverage is restored is expected 'out of the box' functionality for end users. Its omission severely impedes the viability of the current email application."

[TEF_REQ] as feature required for TEF build.

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Just wondering, wouldn't this be more of "there's no concept of a Drafts folder"?  Outbox to me is more of a Sent folder... meaning already sent...

Comment 2

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Also to note, I believe that this was out of scope for v1.  Andrew, is that correct?

Comment 3

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

Yes, this was out-of-scoped for v1 which is why we made mail sending synchronous with that spinner graphic.  But outbox is 100% the right concept.  If you hit send and we're offline or otherwise unable to send, we need some UI affordance to convey to the user that the message has not been sent yet, and potentially have the ability to cancel sending the message.

Comment 6

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

This is a distinct issue from drafts (which is what bug 838012 is about).  See https://bugzilla.mozilla.org/show_bug.cgi?id=838012#c3

Comment 7

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

(In reply to Arun Balachandran Ganesan [:abc] from comment https://bugzilla.mozilla.org/show_bug.cgi?id=838012#c8)
> Andrew:
> 
> I'm adding indicators to the 'sending mail' screens and I need the following
> info:
> 
> How long does it typically take to send an email without any attachments?

I would say usually a few seconds or less, but this is really a function of network and the size of the message.  My unagi in 2G mode is orders of magnitude slower at this than my unagi on wi-fi.  We do have the ability to figure out what type of connection we are on, although it currently requires asking for a lot more privileges than it should because the "connection" API is not implemented for b2g.
 
> If we send an email with attachments and it takes time, is there anyway to
> know 
> i) how long it will take in seconds ?
> ii) or how much percentage of it is sent to show progress?

Short answer: Yes, but it will take some work.  Also, since that's about sending, that's not this bug.

Long answer:

We currently stringify the entirety of a message we are sending rather than streaming it.  It's a deficiency, but it does make it possible to exactly estimate what we are sending.  If/when we move to streaming, we would have more of a ballpark estimate because we might not be able to entirely predict encoding costs for cases like quoted-printable encoded body parts.

For ActiveSync sending, we can use XHR's upload's progress event.  For SMTP I think we might need to actually move to a streaming implementation, or at least wrap our giant-serialized string in one so we can see the progress.

The amount of work to get these working is high enough that it probably would make more sense to devote that effort to background/async mail sending first, especially if our background sending UI isn't going to show a progress bar.  (Once mozNotifications is capable of showing progress bars, it would make sense to potentially show mail sending in there with a progress bar.)


> Also, I think we will need an Outbox (local only will be good enough) to
> save the unsent emails that users can send later. Do you have any specific
> thoughts on that?

An outbox for our purposes would only ever be a local thing, and yes, we'd need one.  The main questions with that are:
- When do we remove a message from the outbox?  When we start sending it since it's now hard to stop it from sending?  Or should we show it in the outbox still while it's sending, but just make it non-cancelable.
- How do we let users cancel sending?

nb: I haven't checked the wireframes recently, those may already be addressed.

Comment 8

[Arun Balachandran Ganesan [:abc]]

(In reply to Andrew Sutherland (:asuth) from comment #7)
> (In reply to Arun Balachandran Ganesan [:abc] from comment
> https://bugzilla.mozilla.org/show_bug.cgi?id=838012#c8)
> > Andrew:
> > 
> > I'm adding indicators to the 'sending mail' screens and I need the following
> > info:
> > 
> > How long does it typically take to send an email without any attachments?
> 
> I would say usually a few seconds or less, but this is really a function of
> network and the size of the message.  My unagi in 2G mode is orders of
> magnitude slower at this than my unagi on wi-fi.  We do have the ability to
> figure out what type of connection we are on, although it currently requires
> asking for a lot more privileges than it should because the "connection" API
> is not implemented for b2g.
>  
> > If we send an email with attachments and it takes time, is there anyway to
> > know 
> > i) how long it will take in seconds ?
> > ii) or how much percentage of it is sent to show progress?
> 
> Short answer: Yes, but it will take some work.  Also, since that's about
> sending, that's not this bug.
> 
> Long answer:
> 
> We currently stringify the entirety of a message we are sending rather than
> streaming it.  It's a deficiency, but it does make it possible to exactly
> estimate what we are sending.  If/when we move to streaming, we would have
> more of a ballpark estimate because we might not be able to entirely predict
> encoding costs for cases like quoted-printable encoded body parts.
> 
> For ActiveSync sending, we can use XHR's upload's progress event.  For SMTP
> I think we might need to actually move to a streaming implementation, or at
> least wrap our giant-serialized string in one so we can see the progress.
> 
> The amount of work to get these working is high enough that it probably
> would make more sense to devote that effort to background/async mail sending
> first, especially if our background sending UI isn't going to show a
> progress bar.  (Once mozNotifications is capable of showing progress bars,
> it would make sense to potentially show mail sending in there with a
> progress bar.)

Got it. I will include a normal spinning indicator to communicate busy status.

> 
> > Also, I think we will need an Outbox (local only will be good enough) to
> > save the unsent emails that users can send later. Do you have any specific
> > thoughts on that?
> 
> An outbox for our purposes would only ever be a local thing, and yes, we'd
> need one.  The main questions with that are:
> - When do we remove a message from the outbox?  When we start sending it
> since it's now hard to stop it from sending?  Or should we show it in the
> outbox still while it's sending, but just make it non-cancelable.
> - How do we let users cancel sending?
> 
> nb: I haven't checked the wireframes recently, those may already be
> addressed.

I will consider these when updating the specs (the specs don't really focus on outbox, but I will putting it up here once it's ready).

Comment 9

[Stephany Wilkes]

What is the latest on this? Do we expect it to make it into 1.2? Thanks!

Comment 10

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

This definitely won't make it into v1.2.  It's not clear that it will make v1.3 either.

Comment 11

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

Duping to the more explicit user story on this.  I'll copy still-relevant comments across.