1059499 - [Email][QuickToTop] New message banner hides when untouched.

Status: RESOLVED FIXED

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

Description

[Yeojin Chung [:YeojinC]]

Attachment: logcat_20140827_NewMessageBannerHids.txt

Description:
New message banner still hides when the email list is not at the top, and the user does not tap on it. 

Pre-requisite: Email account is set up in Email app. The email account has enough emails to scroll in the inbox.

Repro Steps:
1) Update a Flame to BuildID: 20140827040203
2) Open the Email app.
3) Scroll down the list so that the latest email is not shown on the screen.
4) Send a new email to DUT.
5) Observe the "1 New Email" banner.

Actual:
New message banner hides in a few seconds.

Expected:
New message banner does not hide until the user selects it.

Flame 2.1

Environmental Variables:
Device: Flame Master (319mb)
BuildID: 20140827040203
Gaia: 6e804a42ab90f4251c7fe8c68731dc1c6abd8006
Gecko: 0753f7b93ab7
Version: 34.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


Repro Frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/12278/
See attached: logcat, video
http://youtu.be/cVeBbE23NnA
See also:
https://bugzilla.mozilla.org/show_bug.cgi?id=989810

Comment 1

[Yeojin Chung [:YeojinC]]

This issue also reproduces on Flame 2.1 (512mb), Open C 2.1:

Flame 2.1

Environmental Variables:
Device: Flame Master (512mb)
BuildID: 20140827040203
Gaia: 6e804a42ab90f4251c7fe8c68731dc1c6abd8006
Gecko: 0753f7b93ab7
Version: 34.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Open C 2.1

Environmental Variables:
Device: Open_C Master
Build ID: 20140827040203
Gaia: 6e804a42ab90f4251c7fe8c68731dc1c6abd8006
Gecko: 0753f7b93ab7
Version: 34.0a1 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

The banner hides when it's untouched and the list is not at the top.

=======================================

This feature was not implemented on v.2.0:

Flame 2.0

Environmental Variables:
Device: Flame 2.0 (319mb)
BuildID: 20140827000204
Gaia: d72f8ad53448aed577c01ff6e11d958463f261e7
Gecko: 2a18149b3ae8
Version: 32.0 (2.0) 
Firmware Version: v123

Open C 2.0

Environmental Variables:
Device: Open_C 2.0
Build ID: 20140827000204
Gaia: d72f8ad53448aed577c01ff6e11d958463f261e7
Gecko: 2a18149b3ae8
Version: 32.0 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

"Quick to top" and the new message banner behavior are implemented on v.2.1.

Comment 2

[KTucker [:KTucker][Inactive 3/4/2016]]

This seems minor so not nominating this to block.

Comment 3

[James Burke [:jrburke]]

Attachment: GitHub pull request

This fixes three issues:

* Bug 1059499: the "N New Messages" should stay around until the user scrolls down or taps on it. This was not in accordance with the UX spec. The old "auto hide after N seconds" logic via _hideNewMessage was kept in there by mistake.

* Bug 1056518: use "N New Messages" instead of "N New Emails" to also match spec. l10n ID was changed to reflect the change in messaging.

* Bug 1056515: "N New Messages" was not centered on the first showing of it, particularly when the Top Arrow was also shown at first.

The last one was the trickiest of them. It was caused by the l10n mutation stuff changing the size later, and also, the full size was not known until it became visible. So I went with the left:50%, transformX -50% solution, so that explicit sizes did not need to be calculated. However for that to work, I had to turn off animation to change the horizontal position then show it.

The end result is much better than before. However, I do notice about a 2px jump at the end of the N New Messages transition. Also, if the Top Arrow is not showing, the animation is not smooth, the N New Messages just pops in. On desktop, it is smooth, so this suggest some sort of animation drop on the device. That pop in effect happened before this changeset though too, so overall this is a better experience, and we can file follow up bugs to get it better. Most importantly, those follow up bugs do not need new l10n strings, so they could land later.

Comment 4

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

Comment on attachment 8481737 [details] [review]
GitHub pull request

r=asuth with some minor l10n comments and one high quality comedic comment that requires no addressing.  Agreed on potentially addressing animation/pre-rendering glitches later.

The impact of the dynamic l10n stuff (in terms of MutationObserver) in the face of potentially complicated layout stuff is interesting.  Totally agreed on saving the polishing until after the strings have landed and holiday weekends are enjoyed and such.

Comment 5

[James Burke [:jrburke]]

Merged in master:
https://github.com/mozilla-b2g/gaia/commit/528c21e348d404f60720b379b8301e15b6c25696

from pull request:
https://github.com/mozilla-b2g/gaia/pull/23525