1144045 - [Email]The "Top' button doesn't disappear while we receive mails.

Status: RESOLVED INVALID

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

Description

[Coler]

Attachment: logcat_1559.txt

[1.Description]:[Nexus 5_v2.2&3.0][Flame2.2] When we receive some mails, the "Top' button doesn't disappear, which conflicts with the TC result.
Found time:15:59
Attachment:logcat_1559.txt, 1559.mp4

[2.Testing Steps]: 
1. Launch Email.
2. longin an account.
3. Drag down the mail list 
**The "Top" button appears. 
4. Receives mail.

[3.Expected Result]: 
4. Refer to TC, the "Top" button should disappear when receiving mails.

[4.Actual Result]: 
4. The "Top" button doesn't disappear.

[5.Reproduction build]: 

N5_3.0:
(affected)
Build ID               20150316160204
Gaia Revision          4868c56c0a3b7a1e51d55b24457e44a7709ea1ae
Gaia Date              2015-03-14 18:50:17
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/436686833af0
Gecko Version          39.0a1
Device Name            hammerhead
Firmware(Release)      5.0
Firmware(Incremental)  eng.cltbld.20150316.192850
Firmware Date          Mon Mar 16 19:29:05 EDT 2015
Bootloader             HHZ12d

N5_2.2:
(affected)
Build ID               20150316002502
Gaia Revision          a6b2d3f8478ec250beb49950fecbb8a16465ff6f
Gaia Date              2015-03-15 14:33:22
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/18619f8f6c5c
Gecko Version          37.0
Device Name            hammerhead
Firmware(Release)      5.0
Firmware(Incremental)  eng.cltbld.20150316.042754
Firmware Date          Mon Mar 16 04:28:10 EDT 2015
Bootloader             HHZ12d  

Flame2.2:(affected)

Build ID               20150316162504
Gaia Revision          d0e09d5e6367e558824f9cbf691da99cedf63037
Gaia Date              2015-03-16 17:14:22
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/793d61bb0bd4
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150316.195035
Firmware Date          Mon Mar 16 19:50:48 EDT 2015
Bootloader             L1TC000118D0

[6.Reproduction Frequency]: 
Always Recurrence,5/5

[7.TCID]: 
13300

[8.Note]
It can be repro on Flame2.2

Comment 1

[Coler]

Attachment: 1559.MP4

Comment 2

[Eric Chang [:ericcc] [:echang]]

FWD to prod QA Teri

Comment 3

[Teri Wen [:twen]]

Nominate for blocking. Regression bug.

Comment 4

[Teri Wen [:twen]]

Coler, please check if this issue exist on v2.1 and v2.0? Thanks.

Comment 5

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

What's TC?

Comment 6

[Teri Wen [:twen]]

I think thats short for test case.

Comment 7

[Coler]

Hi Teri, 

  This issue CAN be repro on Flmae2.1. On Flame 2.0, there is no "Top" function in Email. Hope this ca help you! Thanks.

Flame2.1(affected):

Build ID               20150318001207
Gaia Revision          13c85d57f49b4bfd657ff674f2b530c141c94803
Gaia Date              2015-03-17 13:31:54
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/2fbd284621e2
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150318.040035
Firmware Date          Wed Mar 18 04:00:46 EDT 2015
Bootloader             L1TC000118D0

Comment 8

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

Ah, so we're talking about https://moztrap.mozilla.org/manage/cases/?filter-id=13300 then.  (I think the TaskCluster project has changed what my brain thinks when it sees TC! :)

There's a mismatch between what the moztrap test case is assuming and how the test appears to be run on this bug.

The test case seems to be written assuming that the user would trigger the retrieval of new messages by hitting the refresh icon.

The test that is being run here per the logcat is depending on periodic sync to fetch the new messages.  I am inferring this because the video had 3:59 on the system status bar and the only entry in the log for a sync corresponding to that time must be a cronsync job because of the concurrent scheduling of sendOutboxMessages.

New message notifications are only generated when explicitly requested by the user by using the refresh icon.

The test case should probably be updated to indicate that the account needs to have periodic sync disabled and that the retrieval of the new mails needs to be performed by hitting the refresh button.

Clearing the blocking flag because this isn't a regression.  (And this also isn't a bug, although perhaps an enhancement is in order to normalize this across all ways of finding out about new messages.  I'm not sure how intentional this behaviour is from a UX perspective.  It might just have been an implementation limitation/simplification.  We'd have to look at the original bug.)

Comment 9

[Teri Wen [:twen]]

Thanks Andrew, for clearing this up. 
Changed test cases to draft since it needs to be updated. 
Resolve bug as invalid since test case is not valid.