998464 - Detect if network goes offline during sign in/sign up flow and notify the user

Status: RESOLVED FIXED

(Firefox OS Graveyard :: FxA, defect, P1)

Description

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

This is in the spec but not yet implemented.

If the user is in the FTE flow, starts to sign up for FxA, but their network connection is wonky, they will enter email, get to the "Connecting..." overlay, and then be literally trapped until the phone is restarted.

We should set a timer when we open the 'Connecting' overlay, and bail after some length of time which is reasonable on crappie 2G networks (maybe 15-30 sec?)

Comment 1

[Sam Penrose]

We have to pay attention to state in Gecko, so that a UX-level cancellation stays in sync with Gecko promises.

Comment 2

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

An alternative UX approach might be to say, "it looks like we're having trouble connecting. Want to continue waiting, or try again later?"

Comment 3

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

I think it's not a blocker. The case where this occurs is pretty remote. Demoting to nice-to-have.

I'm not even sure this is a good fix, maybe giving the user a cancel button is better: what if their network is laggy/droppy, but they know that, and don't want us to give up for them?

Comment 4

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

P3 until/unless QA process shows us that this occurs frequently

Comment 6

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

Since this bug has turned up in independent QA testing, bumping priority and asking for review on priority.

Bhavana, any thoughts on whether this should block 2.0? The description in the duplicate bug 1026603 is much more complete.

Comment 7

[bhavana bajaj [:bajaj]]

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #6)
> Since this bug has turned up in independent QA testing, bumping priority and
> asking for review on priority.
> 
> Bhavana, any thoughts on whether this should block 2.0? The description in
> the duplicate bug 1026603 is much more complete.

Hi Jaredm,

I've asked a question in https://bugzilla.mozilla.org/show_bug.cgi?id=1026603#c4, lets wait to here back on that usecase before making a (non)blocking call here.

Comment 8

[bhavana bajaj [:bajaj]]

Clearing the nom per https://bugzilla.mozilla.org/show_bug.cgi?id=1026603#c5

Comment 10

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

Priority bump for 2.1

Comment 11

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

Attachment: Github PR 23222

Hey Borja!

Do you have time to take a look at a small firefox accounts bug? If not, care to recommend any other reviewers while ferjm is out?

Thanks!

Jared

Comment 12

[Borja Salguero [:borjasalguero]]

Comment on attachment 8477618 [details] [review]
Github PR 23222

Hi Jared! Small comments in the PR quite easy to address and we are ready to merge this.
After reading the requirement, I was thinking that probably we should add a 'cancel' button in every 'overlay' with a spinner, and this would let the user to cancel the request (because if something happens -for example the server needs more than 30 seconds to answer in an horrible 2G connection-), the user could feel that the UI is blocked or frozen. We should improve this in the future as a nice-to-have for our UX, but as in a different bug. Thanks for your patch!

Comment 13

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

Awesome, thanks Borja! Updated, waiting on gaia-try before merging.

Comment 14

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

Tests are green (except for Gij, which doesn't seem reliable these days). Merging.

Master: https://github.com/mozilla-b2g/gaia/commit/95b316b188e133516234c8489f9fe3a1db26c593