It seems that we are triggering a logout from the device when a email verification is done. I am using the legacy server (https://api-accounts-legacy.dev.lcip.org/v1) for these tests: Gecko I 1389643719342 FirefoxAccounts DEBUG (HAWK request) - URI: https://api-accounts-legacy.dev.lcip.org/v1/raw_password/account/create - Method: POST - Payload: {"email":"667861406d61696c696e61746f722e636f6d","password":"12345678"} Gecko I 1389643721654 FirefoxAccounts DEBUG (Response) Code: 200 - Status text: OK - Response text: {"uid":"05a757bfa73246659158475c43975a77"} Gecko I 1389643721671 FirefoxAccounts DEBUG (HAWK request) - URI: https://api-accounts-legacy.dev.lcip.org/v1/raw_password/session/create - Method: POST - Payload: {"email":"667861406d61696c696e61746f722e636f6d","password":"12345678"} Gecko I 1389643724213 FirefoxAccounts DEBUG (Response) Code: 200 - Status text: OK - Response text: {"uid":"05a757bfa73246659158475c43975a77","verified":false,"sessionToken":"b4db08308a68e0b9eb63ae95abe0ead3b1c9a4c43ab28d99601437f58532158f"} Gecko I 1389643734069 FirefoxAccounts DEBUG (HAWK request) - URI: https://api-accounts-legacy.dev.lcip.org/v1/recovery_email/status - Method: GET - Payload: undefined Gecko I 1389643734335 FirefoxAccounts DEBUG (Response) Code: 200 - Status text: OK - Response text: {"email":"fxa@mailinator.com","verified":true} Gecko I 1389643734341 FirefoxAccounts DEBUG checkEmailStatus -> {"email":"fxa@mailinator.com","verified":true} Gecko I 1389643734640 FirefoxAccounts DEBUG fetchAndUnwrapKeys: token: undefined Gecko I 1389643734641 FirefoxAccounts DEBUG Polling aborted; Another user signing in Gecko I 1389643734642 FirefoxAccounts DEBUG generationCount: 5 Gecko I 1389643734669 FirefoxAccounts DEBUG Notifying observers of fxaccounts:onlogout It seems that we are not getting at [1] the 'keyFetchToken' value expected for [2] and so we are signing out. [1] http://mxr.mozilla.org/mozilla-central/source/services/fxaccounts/FxAccounts.jsm#333 [2] http://mxr.mozilla.org/mozilla-central/source/services/fxaccounts/FxAccounts.jsm#162

I was not able to reproduce with Friday's m-c and either Gaia main from today or an older branch. I upgraded m-c and now Gaia main won't get through FTU for me. The older branch, fxa_proposal_complete, still allows me to sign up and verify with no problem. As m-c and gaia main are updated I will try to get past FTU.

(In reply to Sam Penrose from comment #1) > I was not able to reproduce with Friday's m-c and either Gaia main from > today or an older branch. I upgraded m-c and now Gaia main won't get through > FTU for me. The older branch, fxa_proposal_complete, still allows me to sign > up and verify with no problem. As m-c and gaia main are updated I will try > to get past FTU. The FTU part is not landed yet, that's Bug 897600, so you'll need to use the Test-FxA-Client app (already in Gaia master, you'll need an engineering build to get the test apps). However, I should have given more clear STR. We are able to login and verify the account, but verifying the account causes a logout event that is not appreciated until the next reboot because of Bug 959535 (we are consuming the cached account even if it has already logged out, I'll fix this in that bug). So the STR would be: - Open Test-FxA-Client app. - Launch FxA flow. - Complete FxA flow sign up process. - Go to your inbox and verify the account. - Check that the account is still logged. - Reboot the device. - Check that the account is no logged anymore. I've recorded a video of the issue: https://vimeo.com/84124597

Note that I've modified the debug message at [1] to include the topic (fxaccounts:logout in this case) of the notification and show the issue in a better way. [1] https://mxr.mozilla.org/mozilla-central/source/services/fxaccounts/FxAccounts.jsm#350

Sam, are you able to reproduce following the STR from comment 2?

ferjm I don't have a flashable device right now, so I can't attempt the STR. One is on order. I would suggest that we assume your diagnosis is correct and move forward without reproducing on other hardware. If you want me to make reproducing a priority, let me know and I will find someone to do it or borrow a device.

(In reply to Sam Penrose from comment #5) > ferjm I don't have a flashable device right now, so I can't attempt the STR. > One is on order. I would suggest that we assume your diagnosis is correct > and move forward without reproducing on other hardware. If you want me to > make reproducing a priority, let me know and I will find someone to do it or > borrow a device. You can test it with b2g-desktop as shown in the video, it is not device dependent. Anyway, it's ok, I just wanted to confirm that it wasn't just me seeing this issue :). Chris, any idea of why aren't we getting the (expected?)'keyFetchToken' value when doing the raw_password requests? I can't find any docs for the raw password API so I don't know if this is a server or a client issue. If it is a client issue, I am also not sure if it is worth fixing it to work with the legacy server since bug 943521 is supposed to change the client soon to work with the new server.

Hi ferjm, 1) Since we made the /raw_password API obsolete, we removed the documentation. Here is an old ref: https://github.com/mozilla/fxa-auth-server/blob/d9e74ff2a0a75be73a308f51f4e9e50bb27cb279/docs/api.md#post-v1raw_passwordsessioncreate As far as I know, this API never returned the keyFetchToken. This is being replaced with /account/login or /account/login?keys=true depending on whether you need the sync keys are not (https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#post-v1accountlogin). I expect FxOS will not need the sync keys (for now), so it should use the former, which will not return the keyFetchToken either. 2) So what happened? I'm not sure. However, I suspect any errors in key fetching prior to Bug 951118 would fail silently (see http://hg.mozilla.org/mozilla-central/diff/f3d509e75433/services/fxaccounts/FxAccounts.jsm). However, the logic in getKeys is weird (http://mxr.mozilla.org/mozilla-central/source/services/fxaccounts/FxAccounts.jsm). 137 getKeys: function() { 138 return this.getUserAccountData().then((data) => { 139 if (!data) { 140 throw new Error("Can't get keys; User is not signed in"); 141 } 142 if (data.kA && data.kB) { 143 return data; 144 } 145 if (!this.whenKeysReadyPromise) { 146 this.whenKeysReadyPromise = Promise.defer(); 147 return this.fetchAndUnwrapKeys(data.keyFetchToken) 148 .then((data) => { 149 if (this.whenKeysReadyPromise) { 150 this.whenKeysReadyPromise.resolve(data); 151 } 152 }); 153 } 154 return this.whenKeysReadyPromise.promise; 155 }); 156 }, This function can return two different promises, depending on whether this.whenKeysReadyPromise exists or not. The lack of the return on line 147 caused any error in fetchAndUnwrapKeys to fail silently because the error wasn't handled. The addition of the return on line 147 bubbles up the error, but now the data and errors are handled by two different promises (???). This seems like a bug to me, or confusing design. Maybe I'm missing something. Perhaps instead we should do 145 if (!this.whenKeysReadyPromise) { 146 this.whenKeysReadyPromise = this.fetchAndUnwrapKeys(data.keyFetchToken); 147 } 148 return this.whenKeysReadyPromise; Regardless, I'm not sure how this ever worked on FxOS with /raw_password, because as far as I know that API never returned a keyFetchToken. One way that could have worked is because of Bug 959825 (this should be added, where keys are not fetched during a login with an already verified email. I.e., keys are currently only fetched after login when the email is unverified and the browser detects it becomes verified. This is the common case after a create account flow. 3) What do we do? I see two options: 1) Move ASAP to /account/login?keys=true on FxOS. This will give you a keyFetchToken. It's weird that FxOS fetches the sync keys when it doesn't need them, but I suspect we'll need them sometime in the future. 2) Don't treat the lack of a keyFetchToken as an error case which logs the user out. Sync on Desktop always requires a keyFetchToken during login, so this error would have to be handled elsewhere. Granted, it's not handled that well as it is, so I'm not sure this option would make it any worse.

Thanks Chris! (In reply to Chris Karlof [:ckarlof] from comment #7) > > 1) Move ASAP to /account/login?keys=true on FxOS. This will give you a > keyFetchToken. It's weird that FxOS fetches the sync keys when it doesn't > need them, but I suspect we'll need them sometime in the future. I'd go with this solution. If I am not wrong bug 943521 is going to do this.

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #8) > Thanks Chris! > > (In reply to Chris Karlof [:ckarlof] from comment #7) > > > > 1) Move ASAP to /account/login?keys=true on FxOS. This will give you a > > keyFetchToken. It's weird that FxOS fetches the sync keys when it doesn't > > need them, but I suspect we'll need them sometime in the future. > > I'd go with this solution. If I am not wrong bug 943521 is going to do this. You are correct.

Closing this as a dup of bug 943521. Feel free to reopen if you disagree.