1037406 - FxA login does not fail correctly when connection times out

Status: RESOLVED DUPLICATE of bug 998464

(Firefox OS Graveyard :: FxA, defect)

Description

[Mark Goodwin [:mgoodwin]]

STR:
1) Go to sign into FxA, e.g. via Find My Device
2) click "Create account or sign in"
3) interrupt network conenctivity (e.g. pull the cable from your wireless router, change some iptables rules, etc.)
4) enter email address and click 'next'

Expected behaviour:
FxA should fail with an error

Actual behaviour:
Flow falls through to signup (it shows the prompt for Age Verification)

Comment 1

[Sam Penrose]

Is the problem that it does not fail soon enough, or that it does not fail with a clean error screen?

Comment 2

[Mark Goodwin [:mgoodwin]]

(In reply to Sam Penrose from comment #1)
> Is the problem that it does not fail soon enough, or that it does not fail
> with a clean error screen?

There are 2 problems, I think:
1) When FxA can't talk to the server, the correct UX is to give some kind of error, not fall through to some (possibly incorrect path); if you're intending to log in, prompting for signup questions is not the right thing to do.
2) When other things are making use of FxA (e.g. Find My Device), you'd expect them to be able to handle errors; as things stand, the only way to hit the error handler is to close the FxA login.

Comment 3

[Sam Penrose]

2) is a bug: FxA should report the error to the user. I personally don't see reporting the error one screen too late as material, but that's up to product.

Jared is out for a chunk of next week; LMK if I should try to field this one.

Comment 4

[Mark Goodwin [:mgoodwin]]

(In reply to Sam Penrose from comment #3)
> 2) is a bug: FxA should report the error to the user. I personally don't see
> reporting the error one screen too late as material, but that's up to
> product.

It's not just one screen too late; it might be the wrong screen.

E.g. if I already have an account, failure leads me to fall out of sign-in flow into 'create account' flow.

Comment 5

[Sam Penrose]

You're quite right; my mistake.

Comment 6

[Sam Penrose]

My guess is we will want to uplift a fix for this; please let us know.

Comment 7

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

This looks an awful lot like bug 1026603, which was closed as a dupe of bug 998464 and declared a non-blocker.

Can we reconsider the nomination here?

Comment 8

[No-Jun Park [:njpark]]

Bhavana, as Jared says above, Bug 998464 was - ed for blocking 2.0 because this involves sudden loss of inernet connection, which was considered pretty remote.  I think since this is quite similar to 998464, we could consider it as a non-blocker.  What's your take on this?

Comment 9

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Hi :salva, I'm going to take this bug if you don't mind. I've been working on FxA for a while now.

Comment 10

[Adam Rogers (:arog)]

This is obviously not ideal, but I would not block due to the very specific network-drop timings required to reproduce. It also seems that the user does not get locked into the flow in the failure case (though they may be confused)   

I'd like to see this a high priority fix for 2.1

Comment 11

[bhavana bajaj [:bajaj]]

(In reply to Adam Rogers (:arog) from comment #10)
> This is obviously not ideal, but I would not block due to the very specific
> network-drop timings required to reproduce. It also seems that the user does
> not get locked into the flow in the failure case (though they may be
> confused)   
> 
> I'd like to see this a high priority fix for 2.1

Thanks, moving it to backlog so we don't lose it.

Comment 12

[Salvador de la Puente González [:salva]]

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #9)
> Hi :salva, I'm going to take this bug if you don't mind. I've been working
> on FxA for a while now.

No problem.