Nudge users to continue with the provider they previously used to sign in

[gtsiolis]

Problem to solve

Following the design updates in #7061, the user can still run into the error[1] we show when they try to continue with a provider they haven't added in /integrations when opening a repository.

Proposal

Following the design updates in #7061, let's nudge users to continue with the most recent provider they previously used to create an account.

This can be probably achieved using browser local storage which stores all existing connections with providers in /integrations. Cc @AlexTugarev because of a previous discussion on this topic and #4696 (comment).

The footnote below the perimary action button could be always visible or only when selected option is a provider not in the stored list in local storage.

Login with nudge about previously used provider

[AlexTugarev]

@gtsiolis, in the proposal from above, two different providers are mentioned. Personally I'd expect to preselect the previously used provider by default.

Also, if there is recently updated information about provider connections, and we can assume that a provider isn't linked with your account, we should not pre-select it here even if the context URL points to it. In such cases it would be good to proceed with a known provider for the login, and let the workspace start page resolve the missing connection from within a session.

[gtsiolis]

Personally I'd expect to preselect the previously used provider by default.

@AlexTugarev You're correct! 🍊

Sorry for not making it clearer above but the screenshot describes the edge case where we pre-select a provider for the user but the user manually changes the provider option to a provider they don't have any connection with based on the second approach described in the issue description:

The footnote below the perimary action button could be 🅰️ always visible or 🅱️ only when selected option is a provider not in the stored list in local storage.

[jldec]

Following the deployment of #6826 (staging at the time of writing) the situation described can be reproduced as follhows

• create a gitpod account with provider-1 (e.g. gitlab) and no additional integrations
• clear cookies or open a totally new browser session
• navigate to a prefixed repo on a different provider (e.g. github)
• ensure that the login-from-context-6826 UI experiment is true in localstorage (change it and refresh if not)
• continue authenticating with the different provider (i.e. github)

The resulting page is even more probematic than described above, because it asks the user to login with a different provider, but single button presented is not the right one, (and the error message is not nicely centered).

NOTE: Since this scenario requires clearing website cookies or using a different browser from the one where users previously logged in., this means that local storage will probably be empty also.

I would suggest ALWAYS nudging toward using a (possibly different) existing account whenever a sign-up is initiated, without depending on guessing that such an account may exist e.g. from localstorage.

[AlexTugarev]

NOTE: Since this scenario requires clearing website cookies or using a different browser from the one where users previously logged in., this means that local storage will probably be empty also.

@jldec, another realistic way to get here: having the http session expire after some time and navigating to gitpod.io. in that case chances are that the local storage remain.

[AlexTugarev]

The resulting page is even more probematic than described above, because it asks the user to login with a different provider, but single button presented is not the right one, (and the error message is not nicely centered).

In case of an auth error as seen above, we should switch to the regular login screen, no?

[jldec]

@AlexTugarev @gtsiolis : How about making this less dependent on browser memory.

During login/signup flow, ALWAYS offer users a chance to login with their existing account before creating a new account. This means that the login/sigup flow would present an extra step, when the identity is not recognized after authenticating:

Thank your for authenticating as @user on <git-provider>
Clicking on 'Continue' will create a new account on Gitpod.
Already have an account? Login

[Continue]

[gtsiolis]

ALWAYS offer users a chance to login with their existing account before creating a new account. Cc @AlexTugarev

@jldec I could be wrong but this would require us to store account conenctions indefinitely, see:

1. Users don't understand how to change Git providers #5975 (comment)
2. Users don't understand how to change Git providers #5975 (comment)
3. Users don't understand how to change Git providers #5975 (comment)