New email doesn't show up after manual refresh

VERIFIED FIXED

Status

Firefox OS
Gaia::E-Mail
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: cjones, Assigned: dkuo)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-basecamp:+)

Details

STR
 (1) Open email app.
 (2) Compose new email to yourself
 (3) Press send
 (4) Press the "refresh" button to manually poll the server

The email is received, but it doesn't appear in the UI.  I could tell it was received because the scroll indicator flashed.  Since I was at the "top" of the email view, this was unexpected.

If I follow the same steps, but instead before step (4) go "all the way to the top", to the search bar, then when the email is received it appears.
Yeah, we fixup the scrollTop whenever inserting messages to avoid having stuff jump all over the screen.  (Although our use of scrollTop is potentially problematic per bug 796474.)

We have no UX guidelines for this right now, various candidates are (some of which I'm proposed before, some are new):
1) Icon in the header.  Works even if we are scrolled waaaay down the folder.
2) Glow at the top of the list in the background or something ambient-ish like that in the list.  Works when we are down the folder, although it may be confusing; varying the glow on distance may not be intuitive.
3) When we the message list is up-to-date (slice.atTop === true) and the newest message is currently visible, have the header show up so no scrolling is required, possibly using animation to make it less jarring to the user.
3b) Do enough so that the lip of the new message is visible.
4) Generate system-notifications in the 'refresh' icon case.  (Currently, all user-triggered synchronizations do not generate system-notifications because it is believed to be redundant.)
5) Use some type of in-app notification, possibly our banner mechanism, to allow the user to jump back up to the top of the list or something like that.
Flags: needinfo?(kyee)
QA - Does this still happen?
Keywords: qawanted
Seems to be working
Status: NEW → RESOLVED
blocking-basecamp: ? → +
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
(In reply to Mark Finkle (:mfinkle) from comment #3)
> Seems to be working

Yes, I think cjones' most specific request has been addressed.  We had a UI bug where we initially scrolled too far down; a fix for that has landed as part of bug 796730 so that we should be properly flush.  I think the things my broader list above touches on are still relevant, so I have filed bug 800402 to track that.

The push that fixed this is:
https://github.com/mozilla-b2g/gaia/commit/9496abb7ed1cdbefd88a58fcc7bef8f7cd099e1b
Assignee: nobody → dkuo
Flags: needinfo?(kyee)
Resolution: WORKSFORME → FIXED

Comment 5

6 years ago
Can't reproduce now
build info
2012-10-23
gaia master: 608ba8a6a931322c96ac1cea7e02f4c4bf9d70fd
gecko: 167d5a73c6aa564d1abcae4654467aa18aba9a3e
Status: RESOLVED → VERIFIED

Updated

6 years ago
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.