825100 - [Email] No option that email message over 250Kb is downloaded partially and user can select to download the rest

Status: RESOLVED WONTFIX

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

Description

[Natalya Kot [:nkot]]

Summary: There is no option that email message over 250Kb is downloaded partially and user can select to download the rest 

Unagi Build ID: 20121217070202

Steps to reproduce:
1. Send the email message over 250Kb to a test account
2. Open email app on device
3. Open received message

Expected result:
-Message is downloaded partially, there is an option to download remaining message and user is able to select it

Actual result:
-Message downloads fully, user has no way to control it 

related Test Cases: #2009

Comment 1

[amiller]

UCID: email-000
https://moztrap.mozilla.org/results/case/61951/

Comment 2

[Nick Davidson]

This is reproing on Unagi Kernal Dec 5  Build 20130130070201 
Gecko:  http://hg.mozilla.org/releases/mozilla-b2g18/rev/94a2d6fcdfde
Gaia:   6369dbf33b622faf4b4d176fed30b77c5c319dfc

CASE #2009

Message downloads fully, user has no way to control it  (other devices have menu option in email of how much of email body user want to download like 5,10,20 kb or full message) this device does not have this settings that user can set - I understand that test case was written against requirement so if such settings or requirements exist, if somebody can point them out - it would be nice.
If it is not by design test case should be removed bug closed.

Comment 3

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

This was original specs : https://wiki.mozilla.org/Gaia/Email

This is no longer the current behavior for v1 and the use case had changed from the time it was written to now.

Test case disabled.  We might want this for the future though.  UX folk?  what do you think?  If not, please close this bug as invalid.

Comment 4

[Casey Yee]

It's not a showstopper but I think it's pretty important given our target market to be able to defer downloading of larger messages.

One other possibility is to have it so that the message on wifi is automatically downloaded regardless of size and to always prompt when using mobile data.

Ultimately this is a product call.

NeedInfo: clee or pdol

Comment 5

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

The 250k thing was never really spec'ed, and that should be done too.  When we sync an e-mail, we basically have:
- 1 or more body parts in the form of text/plain or text/html
  - if text/html, 0 or more embedded attachments referenced by the text/html
- 0 or more attachments

We know the bandwidth transfer cost of each body part or attachment.

text/plain can easily be truncated without a big problem.  There is no layout, so just the text at the bottom goes missing.

text/html is much less likely to do something good if you truncate it.  On the other hand, 250k is a *lot* of HTML and suggests a badly designed newsletter/one that's trying to game the system, or that it's the output of some automated process like a report from some service.  The system gaming would be to try and use data URI's to encode images to get around other bandwidth caps.


I think a better way to pose this family of settings along this line.  I am picturing a somewhat more chatty scrolling form to pick these things, because even as the developer of an e-mail app, I find the terse settings choices highly confusing and would have trouble guessing what an app would do in the various possible permutations of messages.


- Automatically synchronize the bodies of messages when they are less than [50K, 100K, ...].  If they are larger, ask me if I want to download the message when I go to view it.

- When a message has externally hosted images:
  - wait for me to press the button to show external images (default)
  - automatically show them when I look at the message, even though it may tell the sender of the message that I am looking at the message and the images can be very large.

- When a message has embedded images:
  - wait for me to press the button to download and show the images (default)
  - automatically download the images [when I start to look at the message, when synchronizing my e-mail] if they are less than [250K, 500K, 750K, 1000K] in size

Comment 6

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

(In reply to Andrew Sutherland (:asuth) from comment #5)
> - When a message has externally hosted images:
>   - wait for me to press the button to show external images (default)

Actually, I would pad this (and probably add an embedded images variant too) out to:

   - wait for me to press the button to show external images (default) for senders I have not explicitly white-listed.  <How?> => "When you are looking at an e-mail, click on the sender's name to bring up a list of options.  In that list is an option: "Automatically show/download images from this sender."

Comment 7

[Casey Yee]

(In reply to Andrew Sutherland (:asuth) from comment #5)
> 
> - Automatically synchronize the bodies of messages when they are less than
> [50K, 100K, ...].  If they are larger, ask me if I want to download the
> message when I go to view it.

Automatically download messages:
Always
Under 50Kb
Under 100Kb
Under 250Kb
Custom (user entered)


> - When a message has externally hosted images:
>   - wait for me to press the button to show external images (default)
>   - automatically show them when I look at the message, even though it may
> tell the sender of the message that I am looking at the message and the
> images can be very large.

Load remote images: On/Off

> 
> - When a message has embedded images:
>   - wait for me to press the button to download and show the images (default)
>   - automatically download the images [when I start to look at the message,
> when synchronizing my e-mail] if they are less than [250K, 500K, 750K,
> 1000K] in size

I think we could probably lump this into the same "Automatically download messages" control.  What do you think?

(In reply to Andrew Sutherland (:asuth) from comment #6)
> Actually, I would pad this (and probably add an embedded images variant too)
> out to:
> 
>    - wait for me to press the button to show external images (default) for
> senders I have not explicitly white-listed.  <How?> => "When you are looking
> at an e-mail, click on the sender's name to bring up a list of options.  In
> that list is an option: "Automatically show/download images from this
> sender."

This is a good idea and noted as a backfill feature.   We'll need to think about how the user might administrate the white-list.   

ps. Sorry for the late replies

Comment 8

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

(In reply to Casey Yee [:cyee] from comment #7)
> > - When a message has embedded images:
> >   - wait for me to press the button to download and show the images (default)
> >   - automatically download the images [when I start to look at the message,
> > when synchronizing my e-mail] if they are less than [250K, 500K, 750K,
> > 1000K] in size
> 
> I think we could probably lump this into the same "Automatically download
> messages" control.  What do you think?

I think that's viable, yeah.  How about this as an implementation:

1) If the message body parts are less than the threshold, we download the message.
2) If the message body parts + embedded images are less than the threshold, we go on to download the body parts.  Otherwise, we stop with just having downloaded the body.  We treat the embedded images as all-or-nothing.

Comment 9

[Peter Dolanjski [:pdol]]

(In reply to Andrew Sutherland (:asuth) from comment #8)
> (In reply to Casey Yee [:cyee] from comment #7)
> > > - When a message has embedded images:
> > >   - wait for me to press the button to download and show the images (default)
> > >   - automatically download the images [when I start to look at the message,
> > > when synchronizing my e-mail] if they are less than [250K, 500K, 750K,
> > > 1000K] in size
> > 
> > I think we could probably lump this into the same "Automatically download
> > messages" control.  What do you think?
> 
> I think that's viable, yeah.  How about this as an implementation:
> 
> 1) If the message body parts are less than the threshold, we download the
> message.
> 2) If the message body parts + embedded images are less than the threshold,
> we go on to download the body parts.  Otherwise, we stop with just having
> downloaded the body.  We treat the embedded images as all-or-nothing.

This approach would work and would satisfy Bug 838013.  I just want to clarify that the user can still choose the automatic download (if within threshold) or manual download option, correct?
Would the threshold be user specifiable?  (I don't think this is as critical as just having the overall option to auto download if within threshold)

Comment 10

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

(In reply to Peter Dolanjski [:pdol] from comment #9)
> This approach would work and would satisfy Bug 838013.  I just want to
> clarify that the user can still choose the automatic download (if within
> threshold) or manual download option, correct?

Right.  No user control would be lost by enabling the automatic image download.  When it triggers, it's as if the user had clicked the download button (during the synchronization process; so before the user could see the message).  When it doesn't trigger, the user is still able to hit that button themselves.


> Would the threshold be user specifiable?  (I don't think this is as critical
> as just having the overall option to auto download if within threshold)

Casey proposed:

(In reply to Casey Yee [:cyee] from comment #7)
> Automatically download messages:
> Always
> Under 50Kb
> Under 100Kb
> Under 250Kb
> Custom (user entered)

As such, I think we're all on the same page about how to fix this/bug 838013.

Comment 11

[BMO Automation]

Firefox OS is not being worked on