971344 - mixed case email authenticates but causes sync to fail

Status: RESOLVED FIXED

(Firefox :: Sync, defect, P2)

Description

[Edwin Wong [:edwong]]

1. fire up nightly with a clean profile
2. setup sync
3. enter : [e-mail]
4. passwd: mozdemomozdemo

actual: you get settings page, but the Desktop Fx UI shows you at not being signed in.

Comment 1

[Edwin Wong [:edwong]]

using [e-mail] syncs as expected.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Chris suggests in bug 963835 comment 18 that this should be working on Desktop since it is handled by about:accounts jelly.

Comment 3

[Edwin Wong [:edwong]]

:gavin agreed, this should be working on desktop but it's not.  We are authenticating correctly but possibly fail when we talk to token server.  We can move it to that component but that's a bit of a guess on my part.

Comment 4

[Chris Karlof [:ckarlof]]

Good catch. It's not the previous "email case problem", which is being addressed, but something else. I can reproduce:

OPTIONS https://api.accounts.firefox.com/v1/account/login [HTTP/1.1 200 OK 610ms]
POST https://api.accounts.firefox.com/v1/account/login [HTTP/1.1 400 Bad Request 152ms]
OPTIONS https://api.accounts.firefox.com/v1/account/login [HTTP/1.1 200 OK 43ms]
POST https://api.accounts.firefox.com/v1/account/login [HTTP/1.1 200 OK 70ms]
1392230152729 Sync.Tracker.Clients  WARN  Changed IDs file clients contains non-object value.

1392230152732 Sync.Tracker.Bookmarks  WARN  Changed IDs file bookmarks contains non-object value.

1392230152733 Sync.Tracker.Forms  WARN  Changed IDs file forms contains non-object value.

1392230152735 Sync.Tracker.History  WARN  Changed IDs file history contains non-object value.

1392230152736 Sync.Tracker.Passwords  WARN  Changed IDs file passwords contains non-object value.

1392230152743 Sync.Tracker.Addons WARN  Changed IDs file addons contains non-object value.

GET https://api.accounts.firefox.com/v1/recovery_email/status [HTTP/1.1 200 OK 165ms]
1392230153002 Sync.BrowserIDManager ERROR Background fetch for key bundle failed: this.whenKeysReadyPromise is null

GET http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/02/2014-02-12-03-02-01-mozilla-central/firefox-30.0a1.en-US.mac.partial.20140211030201-20140212030201.mar [HTTP/1.1 206 Partial Content 193ms]
A promise chain failed to handle a rejection.

Date: Wed Feb 12 2014 10:35:52 GMT-0800 (PST)
Full Message: Error: KeyFetch aborted; Another user signing in
Full Stack: abortExistingFlow@resource://gre/modules/FxAccounts.jsm:290
signOut@resource://gre/modules/FxAccounts.jsm:296
task@resource://gre/modules/FxAccounts.jsm:347
TaskImpl_run@resource://gre/modules/Task.jsm:217
TaskImpl@resource://gre/modules/Task.jsm:182
Task_spawn@resource://gre/modules/Task.jsm:152
FxAccountsInternal.prototype.fetchAndUnwrapKeys@resource://gre/modules/FxAccounts.jsm:387
FxAccountsInternal.prototype.getKeys/<@resource://gre/modules/FxAccounts.jsm:332
Handler.prototype.process@resource://gre/modules/Promise.jsm:767
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm:531
 FxAccounts.jsm:290

Comment 5

[Chris Karlof [:ckarlof]]

I believe I tracked this down. There was a bug in the fxa-js-client such that after a "email case error" it didn't include ?keys=true in the retry to /account/login. This caused the second call to not return the keyFetchToken, which is causing the strange errors. We certainly need better error handling and sanity checking for things that should "never" happen like this. This issue was fixed as a side effect of this patch:

https://github.com/mozilla/fxa-js-client/commit/02cc69acff9ef87e11a0827f8dae712f8019685d#diff-9f20221066a888d5c711f89f8e165858L119

and will hopefully be fixed once train-02+ is deployed. Edwin can you verify this is resolved after train-02 goes out? I'll leave this open until then.

Comment 6

[Edwin Wong [:edwong]]

verified that this is fixed 2/26 nightly