Closed Bug 800449 Opened 8 years ago Closed 8 years ago

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

Categories

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

x86_64
Linux
defect

Tracking

(blocking-basecamp:+)

VERIFIED FIXED
B2G C1 (to 19nov)
blocking-basecamp +

People

(Reporter: asuth, Assigned: asuth)

References

Details

(Keywords: feature)

Attachments

(3 files)

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.
blocking-basecamp: --- → ?
Flags: needinfo?(kyee)
blocking-basecamp: ? → +
Priority: -- → P2
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)
(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?
(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.
Casey, can you reply to my questions in comment 2?  Thanks
Flags: needinfo?(kyee)
Priority: P2 → --
Priority: -- → P3
Assignee: nobody → bugmail
Duplicate of this bug: 804379
Keywords: feature
Priority: P3 → P1
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)
(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?
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 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)
Attachment #685307 - Flags: feedback?(squibblyflabbetydoo) → review?(squibblyflabbetydoo)
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+
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
Closed: 8 years ago
Resolution: --- → FIXED
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
Device: Unagi
Build: 20121231070201
Does not repro.
Status: RESOLVED → VERIFIED
Device: Unagi
Build: 20130102070202
Reproduces in current build. Re-open never ending load occurs
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Do you have steps to reproduce? A logcat? What is the domain of the email address you tried this on?
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
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Attached file Log cat
Tested using Google and Hotmail domains.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Marking Resolved Fixed and opening a new bug as requested by asutherland
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Verified with Unagi, build ID 20130103070201
Status: RESOLVED → VERIFIED
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.