Improve FxA's UI if auth/oauth/profile cannot be reached

[data-sync-user]

I thought we had a bug open about this already, but if, e.g., the oauth server is down when loading FxA to authenticate to an OAuth RP, we just show a spinner:

After > 1 minute, the request time out and a 500 page is displayed:

If the auth server is down when trying to sign in, a spinner is displayed on the button for ~ 30 seconds after which time an "Unexpected Error" is displayed:

If the profile server is down when trying to sign in with a cached account, we show a spinner for > 1 minute before showing the default profile photo:

While testing, I myself thought the system might be broken after ~ 30 seconds and totally non-responsive. I can't help but wonder how we can improve this.

Some ideas:

• Poll on the backend to determine if any of the services are down, and if so, show a "be back later" screen. I'm not sure how this would pan out in practice since we run a whole bunch of servers on load balancers and any time a server stops responding, the load balancer pulls it out of action and spins up a new instance. Could an entire load balancer stop responding?
• Drop the XHR request timeout to 15 seconds universally.

cc @rbillings, @bakulf, @pdehaan, @davismtl

┆Issue is synchronized with this Jira Task

[data-sync-user]

➤ Alex Davis commented:

+1 We've seen in stats in the past that when this happens, people do the only thing they can.... start password resets. 🤷‍♂️

show a "be back later" screen

A big yes. Messaging is key. My message proposal "It's not you, it's me. I'm currently not available." style message. LOL

[data-sync-user]

➤ Ryan Kelly commented:

We could definitely do with much clearer messaging here. I think both options described are worth pursuing.

1) Have servers reliably return error codes rather than allowing requests to drag on for a minute or more. This could be achieved by better managing timeouts on the server, automated monitoring, or even a manual switch to put the system into a "down for maintenance" state. In any case, when we get a 2XX errno ( https://github.com/mozilla/fxa/blob/master/packages/fxa-auth-server/lib/error.js#L97 ) from the server, we can safely show the kind of messaging Alex suggests above.

2) Set shorter network timeouts on the client. In this case we don't actually know that "It's not you, it's me", e.g. the user might legitimately be on a flaky network, have antivirus intercepting their connections, or some other client-side shenanigans. A separate message about "having trouble connecting to the servers" is probably valuable here.

[data-sync-user]

➤ Vijay Budhram commented:

from mtg: Per @shane-tomlinson we could shorten XHR timeouts for an easy win. Good future train item.

[data-sync-user]

➤ Shane Tomlinson commented:

So it turns out that if the OAuth server's /token endpoint doesn't respond, the settings page is totally unusable:

https://user-images.githubusercontent.com/848085/65532908-95e96c00-def4-11e9-8aa6-86574bbdbe9a.png

[cknowles-admin]

FxA is no longer synchronizing all issues between Jira and Github. We are closing open issues and will selectively synchronize in the future.