*** Description gaia-ui-test test_IMAP_email_notification fails. *** Steps to Reproduce * Run the gaia-ui-test test_IMAP_email_notification Alternatively * Login to a valid gmail account in E-Mail app. * Enable the notification in email settings * Send an email to the account * Wait for notifications *** Expected Results Notification pops up *** Actual Results No notification, even after sync. *** Other Notes *** Reproduction Frequency 100% 5/5 *** Build Device firmware (base) L1TC000118D0 Device firmware (date) 15 Feb 2015 17:09:03 Device firmware (incremental) eng.cltbld.20150215.040852 Device firmware (release) 4.4.2 Device identifier flame Gaia date 13 Feb 2015 13:27:43 Gaia revision ea64caf6d4ab Gecko build 20150215002504 Gecko revision 62c80c92b39e Gecko version 37.0a2
[Blocking Requested - why for this release]: Per the smoketest report, Shing said this issue was reproducible manually. Hence, this looks like a bug in the production code. QA wanted for a branch check.
Status: NEW → RESOLVED
blocking-b2g: 2.2? → ---
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1132479
I don't think this is a duplicate of bug 1132479. Bug 1132479 is about the failure in test_IMAP_email_notification, the email notification did still work at the time, afaik. This bug says the email notification doesn't work at all.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
The provided python log indicates that a timeout is firing after 30 seconds which would be well under the 100 second sync minimum interval, which is why I duped. It's also possible this is bug 1118711, or even something unknown. But we need a logcat for that. (Which we always need.) :slyu, do you have a logcat from any of the failed runs available? Thanks!
Removing the regression window while we get the branch check executed. Also, can we get a logcat like asked in comment 4?
Ok, with the directions of Andrew Sutherland (thanks Andrew!), I was able to fix the test_IMAP_email_notification automated test. I think that makes this bug automatically a duplicate of bug 1132479, because it's apparently still working on the latest trunk. Shing Lyu, can you confirm?
This issue occurs on Flame 2.2. Observed behavior: 1) email doesn't seem to automatically sync. With automatically sync set to 100 seconds and email app running in background, I waited on Homescreen for 3 minutes after sending an email to myself and it didn't check for new email at all (new email wasn't present when I brought email to front and at bottom of email app it didn't say it was recently synced). 2) No new email notification when I manually sync'ed email. It displayed the new email without playing a sound or displaying notification banner on top of screen. This seems to be an expected behavior because this is what happens in 2.1 - with email app already opened in active window it won't display notification whether it's manually syncing or auto syncing. Tested with gmail on 319MB memory shallow flashed flame. Device: Flame 2.2 BuildID: 20150217094829 Gaia: 3d5bc54ec9c208a23f48741000251974148c6df3 Gecko: e6b98537b016 Version: 37.0a2 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 --------- This issue does NOT occur on Flame 2.1 or on Flame 3.0. The abovementioned (1) does not occur; notification banner appears and sound plays when receiving an email with email in the background. (2) occurs. Device: Flame 2.1 BuildID: 20150217093136 Gaia: 221e911a388916834d5da40190c52189b1676b21 Gecko: 36e5b43c1970 Version: 34.0 (2.1) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Device: Flame 3.0 Master BuildID: 20150217112337 Gaia: 4f39e48b95fa00c8669b8707447542024bb55432 Gecko: 7f7e833005ea Version: 38.0a1 (3.0 Master) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 ---------- Attaching a logcat on Flame 2.2. Logcat is for idling at Homescreen waiting for email to automatically sync (which never happened), and after 3 minutes went to email to see there was no new email and then manually sync'ed to get email.
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?]
Hmm, for 2.2, I see this in the log: I/GeckoDump( 2020): WAR: no navigator.sync support! which seems like navigator.sync is not in the 2.2 version of gecko used. This also seems to be corraborated in bug 1131963 comment 5. As the requestsync API was a 2.2 feature, tracked in bug 1018320, I will follow up on why that is the case. If it is not going to land for 2.2, then we will need to revert the email change that uses it.
I don't see any mentioning in bug 1018320 that it was fixed for 2.2. Andrea, was the patch for bug 1018320 checked in for 2.2?
Summary: [Email] No new email notification → [v2.2][Email] No new email notification
I have also asked in bug 1018320 if navigator.sync will be in 2.2. For now, I will work on backing out the email change to use navigator.sync in the 2.2 branch.
I just reverted the request.sync changes in email on the v2.2 Gaia branch to go back to using alarms as it previously did: https://github.com/mozilla-b2g/gaia/commit/da509caa7395d3d090ce973e8de082b4680a590d Which should fix the issue for any build that includes that revert.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago → 4 years ago
Resolution: --- → FIXED
Verified fixed. Gaia-Rev e4bf968d5a7366e7bdc58f0fdba28b32e864bdf7 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/da6ac51f5113 Build-ID 20150225162504 Version 37.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20150131.200206 FW-Date Sat Jan 31 20:02:17 EST 2015 Bootloader L1TC000118D0
Status: RESOLVED → VERIFIED
Forgot to check the default setting, we have 'manual' in v2.2, is that what we have in automation?
(In reply to Eric Chang [:ericcc] [:echang] from comment #14) > Forgot to check the default setting, we have 'manual' in v2.2, is that what > we have in automation? Hi Eric, The email will check for new messages every 20 seconds after running gaia-ui-test test_IMAP_email_notification.py Thanks!
Per Comment 13,clear "verifyme" and set as verified.
You need to log in before you can comment on or make changes to this bug.