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)

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

(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.

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.

(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.

You're quite right; my mistake.

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

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?

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?

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

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

(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.

(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.