1204113 - [Email] After user sets up new account, re-opening email app for the first time brings user to New Account screen.

Status: VERIFIED FIXED

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

Description

[Nicholas Nelson [:NicholasN]]

Attachment: logcat_email.txt

Description:
The user sets up a new email acount and proceeds to the inbox. They hold the home button and close the app. When they re-open the app, they are shown the New Account screen. After closing the app again and re-opening it, they are brought to their inbox.


Repro Steps:
1) Update a Aries to 20150911153729
2) Open the email app.
3) Set up an account and proceed to inbox.
4) Tap and hold home button to open card view, and close the email app.
5) Re-open the email app.


Actual:
User is brought to New Account screen the first time they re-open the email app.


Expected:
User is brought to their inbox if they have an account set up.


Notes:

Environmental Variables:
Device: Aries 2.5
Build ID: 20150911153729
Gaia: 758c75ee087ea3722213ea2c185cca1d952c8a29
Gecko: 7b1cfb1606ec447506bf7373b645b7a09f3aa238
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 43.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

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

Comment 1

[Nicholas Nelson [:NicholasN]]

Issue also reproduces on Flame 2.5, but not on Flame 2.2

Flame 2.5

Actual Result:

Re-opening email app after creating account brings user to New Account page.

Environmental Variables:
Device: Flame 2.5
BuildID: 20150911103006
Gaia: 758c75ee087ea3722213ea2c185cca1d952c8a29
Gecko: 19f806034f67e8fc84b352db10f1a21ab982670f
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 43.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Flame 2.2

Actual Result:

Re-opening email app brings user to their inbox.

Environmental Variables:
Device: Flame 2.2
BuildID: 20150909183023
Gaia: 7a427e0f8aa6c185a9e22358006b97c19435ca4a
Gecko: 0d9c46d01861
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 2

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

[Blocking Requested - why for this release]:

This could lead to end user frustration so nominating this to block.

Comment 3

[Pi Wei Cheng [:piwei] (inactive)]

I can't reproduce this issue using gmail or outlook accounts. Tried ~8 times and can't repro. I had the reporter try it on my device and he was able to repro on 2nd attempt using his gmail account. In any event this is not 100% reproducible. Flagging steps wanted to see if we can get better steps.

Comment 5

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

The logs indicate we're not saving the "data_has_account" option to local storage correctly during the first invocation.  Presumably this is a result of the recent refactoring.  saveHasAccount() has a guard that causes it to only save stuff for the default model.  It also is only called in the oncomplete notification for the slice or the change notification, so maybe there's a race there somehow?  (Overzealous guard makes more sense.)

To summarized log-wise, in the initial open, we save a no value and never save a yes.  Then next time we start up we show the wrong UI, the database tells us the right thing and we update that to a yes.  But I guess we no longer reset the UI?

Comment 6

[Martin Shuman [:Marty]]

I believe I have found solid STR for this issue. I found it necessary to use the ‘Manual setup’ option, as I couldn’t reproduce the issue using automatic setup.  I also specifically used a Gmail account.

1) Update a Aries to 20150911153729
2) Open the email app.
3) Log into a Gmail account via Manual Setup, using ‘imap.gmail.com’ and ‘smtp.gmail.com’ servers.
4) Continue through the initial account setup to the inbox.
5) At the inbox, long-press the home button and close the E-Mail app.
6) Launch the E-Mail app again from the Homescreen.

Using these steps, I was able to reproduce this issue on the latest Flame and Aries 2.5 Master builds.

Repro Rate: 7/7 times (2 on Aries, 5 on Flame)

Environmental Variables:
Device: Aries 2.5
BuildID: 20150914130903
Gaia: f37e8f732e0af961b43e912629c84c9e2ceda55d
Gecko: fba4b0cd3823975949765acc0b16b964d1712b75
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 43.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Environmental Variables:
Device: Flame 2.5
BuildID: 20150914030233
Gaia: 4d9b996be4b1935651057d0651461c1a36d98a18
Gecko: 9ed17db42e3e46f1c712e4dffd62d54e915e0fac
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 43.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0


This issue does NOT occur on the latest Flame 2.2 build.
The user will briefly see the login screen, but within one to two seconds, the app will then properly load the account inbox.

Environmental Variables:
Device: Flame 2.2
BuildID: 20150914032507
Gaia: 7a427e0f8aa6c185a9e22358006b97c19435ca4a
Gecko: 0d9c46d01861
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 7

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

Let's get a window here.

Comment 8

[GitHub Autolander Bot]

Attachment: [gaia] jrburke:bug1204113-email-cache-has-account > mozilla-b2g:master

Comment 9

[James Burke [:jrburke]]

Comment on attachment 8660958 [details] [review]
[gaia] jrburke:bug1204113-email-cache-has-account > mozilla-b2g:master

Funny story, a case of "this" not being bound to the correct object for the acctsSlice.onchange listener. Thinking more about it, the model === defaultModel check is not needed, we really want to update that cache state no matter what model instance fetched the accounts: we want the reality of the backend reflected. Additionally, model_create does not know for sure if its consumers ever actually will use the defaultModel.

So I removed the need to check the model instance, but also updated the onchange listener to be bound correctly just in case later code is introduced. In the convoy branch, these binds are now all arrow functions. I did not do that here to match existing style, but will do so when merging the change to the convoy branch.

As to not correctly resetting if the cache is wrong, that is a deeper issue, something I am currently working on in the convoy branch. I believe it is a larger change, and would prefer to just keep going on the convoy branch for that issue. Once I come up with something there, we can decide if we need to backport or just push to get convoy in total in master. With this change, the cache should not be incorrect now.

This issue would have been avoided if the eslint rule around this/arrow/bind usage was in effect. I will look more into that soon, but will likely try to clear some other master bugs from the decks first.

Comment 10

[James Burke [:jrburke]]

For the regression window, it was introduced in https://github.com/mozilla-b2g/gaia/commit/e4ccafe5bcfe0e7c823e1189d5903451e0faa038, the fix for bug 1196077.

Comment 11

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

Comment on attachment 8660958 [details] [review]
[gaia] jrburke:bug1204113-email-cache-has-account > mozilla-b2g:master

I'm glad it was just a "this" issue... otherwise it seemed like the problem was going to be super-complicated!

I agree on punting on the reset logic to the convoy branch.  We only need the reset logic to work in the event that there is a disagreement between local storage and the database.  We only expect this to occur in cases where the backend performs a complete database nuking which has never occurred yet.  (It will imminently occur on the convoy branch, but it's within our power to migrate the account definitions with some low-to-medium legwork.)

Comment 12

[James Burke [:jrburke]]

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

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

Comment 13

[Martin Shuman [:Marty]]

This issue is verified fixed on the latest Spark 2.5 builds.
The user is properly brought back to the inbox when relaunching the app, and is not presented with the new account sign in screen.

Environmental Variables:
Device: Aries 2.5
BuildID: 20150915141659
Gaia: d2e5c49440bf8410ae747b15c0dd11c54053ef3e
Gecko: 5d61714cf5c3ec2440e9491ba30893ac37ca06c2
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 43.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Environmental Variables:
Device: Flame 2.5
BuildID: 20150915060640
Gaia: d2e5c49440bf8410ae747b15c0dd11c54053ef3e
Gecko: 5d61714cf5c3ec2440e9491ba30893ac37ca06c2
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 43.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0