1115039 - [Email] Email will not be updated/checked while the app is closed

Status: RESOLVED DUPLICATE of bug 1118711

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

Description

[Adam Alldredge [:AdamA][Inactive]]

Attachment: logcat_20141223_0901.txt

Description:
If the user closes the email app and receives another email the app will not check to see if new emails have been received.

Repro Steps:
1) Update a Flame to 20141223010202
2) Open email app and sign into an account
3) Set the email app to to check for email periodically
4) Hold the homebutton to open cardview and close the email app
5) Send an email to the account that is signed in
6) Wait the set amount of time to see if the user receives a new email notification.

Actual:
Email is not checked while the email app is closed

Expected:
It is expected that email will be checked while the email app is closed

Environmental Variables:
Device: Flame 2.2 (319mb)(Kitkat Base)(Full Flash)
Build ID: 20141223010202
Gaia: c2da2bafd4e809317e2ca70c9bf5c11136a32818
Gecko: 0532f2509f3f
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 37.0a1 (2.2)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Notes:
In email app settings if the user taps 5 times a debug menu will be open that allows the user to set the email check time to 20 seconds.

Repro frequency: 5/5
See attached: video clip, logcat

Comment 1

[Parul Mathur [:pragmatic] - out of office - please ni? [:bajaj] instead]

:asuth, do you think this is a blocker?

Comment 2

[Adam Alldredge [:AdamA][Inactive]]

This issue does NOT repro on Flame 2.1.

Environmental Variables:
Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
Build ID: 20141223001203
Gaia: 17c7ad2e4919a994f0844239b483116090412dee
Gecko: 39dfb662c82a
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 34.0 (2.1)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Result:
Email updates while email app is closed.

Comment 3

[Peter Bylenga [:PBylenga]]

Functional regression of a core feature.

Requesting a window.

Comment 4

[Duane Dixon [:ddixon]]

Unable to provide a Regression Window here.  Issue only occurs in the reported Flame 2.2 (full flash, nightly).

Unable to reproduce issue in the latest Flame 2.2 engineering-tinderbox build: 

Environmental Variables:
Device: Flame 2.2 (shallow flash, 319 MB memory, engineering)
BuildID: 20141223101736
Gaia: 0db8a38f9fed18ae2abf5ef7e1b6e2a570b07e0e
Gecko: 44344099d119
Version: 37.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 5

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

I'm confused by comment 4.  Are we saying this only occurs on a single specific device/account, or just on a specific build?  Based on my analysis below, if it's just a build, then I think we can just resolve this WFM.  If it's a specific device/account, we probably want https://wiki.mozilla.org/Gaia/Email/SecretDebugMode used to turn the mode up to the "realtime logging" mode and then privately send me the log at [e-mail].


The freaky error in the logcat is a recursion explosion:

12-23 12:01:37.150  7957  7957 I GeckoDump: LOG: email startedInBackground
12-23 12:01:37.310  7957  7957 I GeckoDump: LOG: cronsync-main: wake locks acquired: [object MozWakeLock] for account IDs: 0
12-23 12:01:37.350  7957  7957 I GeckoDump: ERR: onerror reporting: InternalError: too much recursion @  : 0

We later close ourselves:
12-23 12:02:22.320  7957  7957 I GeckoDump: LOG: email: cronsync wake locks expired, force closing app


Given that we see the wake lock expiration and we don't see "WLOG: cronsync: received an alarm via a message handler" from the worker, one possibility would be if cronsync-main.js got into a weird loop with dispatcher._sendMessage where _routeReady ended up false when dispatcher.hello finally happened.  That should really really really not happen, but if there was a build where the minifier or the JS engine was badly bugged, that could maybe explain things.

Comment 6

[Parul Mathur [:pragmatic] - out of office - please ni? [:bajaj] instead]

:Joshua_M, please provide the detailed logcat requested in comment #5.

Comment 7

[Joshua Mitchell (Inactive)]

QA-Wanted: To verify this does not occur on the latest 2.2 Nightly Build

If it does not repro, let's close this as WFM
If it does repro, let's get the logcat info requested

Comment 8

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

I was unable to test this bug on any nightly builds past December 23rd. All builds are blocked due to bug 1116087. Leaving the qawanted request to retest once the merges have gone through. created and sent an email to [e-mail] with a detailed log from the reported build of this bug.


Device: Flame 2.2
BuildID: 20141231010205
Gaia: 26d479f0fccb7174e06255121e4e938c1b280d67
Gecko: 88037f94b7d7
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 37.0a1 (2.2)
Firmware: V18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 9

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Now that bug 1116087 is fixed I have been able to confirm that this occurs on the latest 2.2 Nightly build as well.  Going to find a regression window again.

Environmental Variables:
Device: Flame 2.2
BuildID: 20150105010205
Gaia: c2bf20d23851d5fda9f8f0ef0267db5f49152376
Gecko: 636498d041b5
Version: 37.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 10

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

A regression window cannot be found for this issue.  This issue only occurs on Nightly user builds and cannot be reproduced on tinderbox builds or Nightly engineering builds.

Tinderbox Engineering - Issue does NOT occur
Environmental Variables:
Device: Flame 2.2
BuildID: 20150105033341
Gaia: 4ceeff19086b2a2955f044ad923dcfa63a293de3
Gecko: 912036eeb024
Version: 37.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Nightly Engineering - Issue does NOT occur
Environmental Variables:
Device: Flame 2.2
BuildID: 20150105010205
Gaia: c2bf20d23851d5fda9f8f0ef0267db5f49152376
Gecko: 636498d041b5
Version: 37.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Tinderbox User - Issue does NOT occur
Device: Flame 2.2
BuildID: 20150105043002
Gaia: 4ceeff19086b2a2955f044ad923dcfa63a293de3
Gecko: 912036eeb024
Version: 37.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Nightly User - Issue DOES occur
Environmental Variables:
Device: Flame 2.2
BuildID: 20150105010205
Gaia: c2bf20d23851d5fda9f8f0ef0267db5f49152376
Gecko: 636498d041b5
Version: 37.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 11

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

(In reply to Derek Harris [:DerekH] from comment #8)
> I was unable to test this bug on any nightly builds past December 23rd. All
> builds are blocked due to bug 1116087. Leaving the qawanted request to
> retest once the merges have gone through. created and sent an email to
> [e-mail] with a detailed log from the reported build of this bug.

Thanks for the log.  The following notable things happen in the log:

- An ActiveSync sync request for Derek's test account failed with a status of 110 (ServerError).  Because the status is reported at a path of AirSync:Sync/AirSync:Status rather than the AirSync:Sync/AirSync:Collections/AirSync:Collection/AirSync:Status that we expected, our code does not perceive the status and treats it as an "undefined" status.  Since this falls through into our catch-all else case, it's not clear this is actually a problem.  The log for this looks like:
WERR: Something went wrong during ActiveSync syncing and we got a status of undefined

- We get another "ERR: onerror reporting: InternalError: too much recursion @  : 0"

Otherwise things look pretty healthy.  Syncs are happening correctly, etc.

Comment 12

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

(In reply to Jayme Mercado [:JMercado] from comment #10)
> A regression window cannot be found for this issue.  This issue only occurs
> on Nightly user builds and cannot be reproduced on tinderbox builds or
> Nightly engineering builds.

Hm, presumably the issue is due to different build parameters causing the stack or stack limit to differ between the builds.  Possibilities are the optimization level, debug level, and/or inclusion of some process that spins a nested event loop in such a way that gobbles up some stack.

I'll look into this some more.

Comment 13

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

Duping forward to bug 1118711 which I believe to be the identical problem and where the investigation happened.