800449 - [email] Make sure UI reflects when we give up on synchronization because of connection problems

Status: VERIFIED FIXED

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

Description

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

If we experience connection problems when trying to synchronize a folder, we do our backoff trick where we try a few times then eventually give up.  The UI does not hear about this (because I think the synchronization layer does not hear about this because its connection request just gets stuck in there) and so continues to spin its little "Loading messages" icon forever.  This is misleading because the user thinks we are trying to do something when in reality we totally gave up and the user needs to do something to cause us to attempt to re-establish a connection.

Casey, we probably need a UI affordance for this.  I would propose that the easiest thing is to have a visible box at the top of the message list that says something along the lines of "Unable to connect to server; retry" which would attempt to reconnect to the server and synchronize.  The rationale for the thing at the top as opposed to a full-screen display like we have for empty folder is that we may be able to display the messages we already know about for the folder.  We would also probably want to display "We are offline, go online to be able to synchronize" or something like that at the top for similar reasons.  Right now, when we are offline we won't bother trying to synchronize because we now it will fail, but there is no UI feedback for this.

Comment 1

[Casey Yee]

I will update wire frames as per my conversation with Andrew on IRC:

- We will warn the user of sync errors on a per-server basis.
- Warning the user of some kind of problem is sufficient.  Errors are generally not actionable by the user other than to simply retry.

To address this:

- Add connection/sync warning icon to account name in drawer.
- Add last sync date/time to bottom of drawer.
- If the user explicitly refreshes a folder and there is a connection/sync error, the user is presented with a dialogue:

"Mail is having problems connecting with the server"
[Cancel][Try again]

Any issues with this approach?

Comment 2

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

(In reply to Casey Yee [:cyee] from comment #1)
> - Add connection/sync warning icon to account name in drawer.

This seems like a good thing.  Would we display it in both the header of the account folder list and also next to the account in the account list?

> - Add last sync date/time to bottom of drawer.

We store these values on a per-folder basis.  Should we display the value for the current folder, the most recent value across all folders, or use something like the inbox as a proxy for the entire account?

> - If the user explicitly refreshes a folder and there is a connection/sync
> error, the user is presented with a dialogue:
> 
> "Mail is having problems connecting with the server"
> [Cancel][Try again]

This works, but would it be better to just use the existing banner (black bubble) system so we can avoid the modal dialog?  We could show "Unable to connect to server [Retry]", and if the user doesn't want to, they can click the X to get rid of it immediately.  It can take us many seconds to realize the server is not talking to us because of network latency, network dropouts, or just general server issues.

We could also do the banner thing for the initial sync when we enter the folder, perhaps?

Comment 3

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

is this a dup of bug 796444?

Comment 4

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

(In reply to Naoki Hirata :nhirata from comment #3)
> is this a dup of bug 796444?

No.  There's some potential overlap for the UI surfacing bits, but that's activesync and this is more IMAP.

Comment 5

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

Casey, can you reply to my questions in comment 2?  Thanks

Comment 7

[Alex Keybl [:akeybl]]

We're marking this bug with the C1 milestone since it follows the criteria of "unfinished feature work" (see https://etherpad.mozilla.org/b2g-convergence-schedule).

If this work is not finished by Nov19, this bug will need an exception and will be called out at the upcoming Exec Review.

Comment 8

[Casey Yee]

(In reply to Andrew Sutherland (:asuth) from comment #2)
> (In reply to Casey Yee [:cyee] from comment #1)
> > - Add connection/sync warning icon to account name in drawer.
> 
> This seems like a good thing.  Would we display it in both the header of the
> account folder list and also next to the account in the account list?

This should be displayed at the bottom right corner of the drawer where we should be displaying last sync information for the account.  

We should also display error icons next to the account that is having sync issues in the account view as well.


> 
> > - Add last sync date/time to bottom of drawer.
> 
> We store these values on a per-folder basis.  Should we display the value
> for the current folder, the most recent value across all folders, or use
> something like the inbox as a proxy for the entire account?

Most recent value across all values would make the most sense.   


> 
> > - If the user explicitly refreshes a folder and there is a connection/sync
> > error, the user is presented with a dialogue:
> > 
> > "Mail is having problems connecting with the server"
> > [Cancel][Try again]
> 
> This works, but would it be better to just use the existing banner (black
> bubble) system so we can avoid the modal dialog?  We could show "Unable to
> connect to server [Retry]", and if the user doesn't want to, they can click
> the X to get rid of it immediately.  It can take us many seconds to realize
> the server is not talking to us because of network latency, network
> dropouts, or just general server issues.
> 
> We could also do the banner thing for the initial sync when we enter the
> folder, perhaps?

Banner works!

Comment 9

[Dietrich Ayala (:dietrich)]

Hi Andrew - any progress on this?

Comment 10

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

The pull request attaching extension is dying, but the not-quite-ready pull request is here:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/82

It also covers bug 805337 and bug 799063 because they're all inter-related.

Comment 11

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

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/82

Pointer to Github pull-request

Comment 12

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

Comment on attachment 685307 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/82

(Github-Bugzilla-Tweaks works in a different profile with a freshly built xpi from source... not sure what's up.)

Comment 13

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

Comment on attachment 685307 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/82

r=squib from github, IRC

Comment 14

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

landed on gaia-email-libs-and-more/master:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/82

landed on gaia/master (review was tracked on inter-related bug 805337):
https://github.com/mozilla-b2g/gaia/pull/6484

Comment 15

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

Some follow-up improvements to ActiveSync that needed a little more love have now landed.

Proper pull request and discussion:
https://github.com/asutherland/gaia-email-libs-and-more/pull/2

Which was landed as the following because the above was on top of the already-landed pull request and I psyched myself out in terms of perceived rebasing:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/87

And which has now landed on gaia:
https://github.com/mozilla-b2g/gaia/pull/6668

Comment 16

[amiller]

Device: Unagi
Build: 20121231070201
Does not repro.

Comment 17

[amiller]

Device: Unagi
Build: 20130102070202
Reproduces in current build. Re-open never ending load occurs

Comment 18

[Jim Porter (:squib)]

Do you have steps to reproduce? A logcat? What is the domain of the email address you tried this on?

Comment 19

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

Please don't reopen bugs that have been fixed for more than a few days.  Please file a new bug.  It is fine to mention the newly filed bug from this bug as a potential regression of the fix so that people can follow any potential trail.

Comment 20

[amiller]

Attachment: Screen shot of never ending load.

Comment 21

[amiller]

Attachment: Log cat

Comment 22

[amiller]

Tested using Google and Hotmail domains.

Comment 23

[cbarker]

Marking Resolved Fixed and opening a new bug as requested by asutherland

Comment 24

[Mila Davydova]

Verified with Unagi, build ID 20130103070201

Comment 25

[Mila Davydova]

New bug (#826118) is created for this issue.

Comment 26

[Tracy Walker [:tracy]]

this is covered in moztrap by test case: https://moztrap.mozilla.org/manage/case/3315/