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

VERIFIED FIXED in B2G C1 (to 19nov)

Status

P1
normal
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: asuth, Assigned: asuth)

Tracking

({feature})

unspecified
B2G C1 (to 19nov)
x86_64
Linux
feature
Bug Flags:
in-moztrap +

Firefox Tracking Flags

(blocking-basecamp:+)

Details

Attachments

(3 attachments)

(Assignee)

Description

6 years ago
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.
(Assignee)

Updated

6 years ago
blocking-basecamp: --- → ?
Flags: needinfo?(kyee)

Updated

6 years ago
blocking-basecamp: ? → +
Priority: -- → P2

Comment 1

6 years ago
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?
Flags: needinfo?(kyee)
(Assignee)

Comment 2

6 years ago
(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?
is this a dup of bug 796444?
(Assignee)

Comment 4

6 years ago
(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.
(Assignee)

Comment 5

6 years ago
Casey, can you reply to my questions in comment 2?  Thanks
Flags: needinfo?(kyee)

Updated

6 years ago
Priority: P2 → --

Updated

6 years ago
Priority: -- → P3
Assignee: nobody → bugmail
(Assignee)

Updated

6 years ago
Duplicate of this bug: 804379
Keywords: feature
Priority: P3 → P1

Comment 7

6 years ago
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.
Target Milestone: --- → B2G C1 (to 19nov)

Comment 8

6 years ago
(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!
Flags: needinfo?(kyee)
Hi Andrew - any progress on this?
(Assignee)

Comment 10

6 years ago
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.
(Assignee)

Comment 11

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

Pointer to Github pull-request
(Assignee)

Comment 12

6 years ago
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.)
Attachment #685307 - Flags: feedback?(squibblyflabbetydoo)
(Assignee)

Updated

6 years ago
Attachment #685307 - Flags: feedback?(squibblyflabbetydoo) → review?(squibblyflabbetydoo)
(Assignee)

Comment 13

6 years ago
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
Attachment #685307 - Flags: review?(squibblyflabbetydoo) → review+
(Assignee)

Comment 14

6 years ago
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
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Comment 15

6 years ago
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

6 years ago
Device: Unagi
Build: 20121231070201
Does not repro.

Updated

6 years ago
Status: RESOLVED → VERIFIED

Comment 17

6 years ago
Device: Unagi
Build: 20130102070202
Reproduces in current build. Re-open never ending load occurs
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 18

6 years ago
Do you have steps to reproduce? A logcat? What is the domain of the email address you tried this on?
(Assignee)

Comment 19

6 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED

Comment 20

6 years ago
Created attachment 697238 [details]
Screen shot of never ending load.

Comment 21

6 years ago
Created attachment 697239 [details]
Log cat

Comment 22

6 years ago
Tested using Google and Hotmail domains.

Updated

6 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 23

6 years ago
Marking Resolved Fixed and opening a new bug as requested by asutherland
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED

Comment 24

6 years ago
Verified with Unagi, build ID 20130103070201
Status: RESOLVED → VERIFIED

Comment 25

6 years ago
New bug (#826118) is created for this issue.
this is covered in moztrap by test case: https://moztrap.mozilla.org/manage/case/3315/
Flags: in-moztrap+
You need to log in before you can comment on or make changes to this bug.