Open Bug 1570565 (fxa-desktop-decouple) Opened 1 year ago Updated 7 months ago

[meta] Decouple "Signing in to Firefox" from "Enabling Firefox Sync"

Categories

(Firefox :: Firefox Accounts, enhancement)

enhancement
Not set
normal

Tracking

()

People

(Reporter: rfkelly, Unassigned, NeedInfo)

References

(Depends on 3 open bugs)

Details

(Keywords: meta)

Currently, signing in to Firefox with your Firefox Account [1] is synonymous with activating Firefox Sync -- all of the onboarding messaging is specific to Sync, and the very presence of an active signin session held by the browser is taken as a signal that it should sync its data to the associated account.

We're adding more Account-related features and services to the browser, such as a the Firefox Monitor protection report card (Bug 1559422). These features should be able to use the browser's sign-in state even if the user doesn't have (or doesn't want) Firefox Sync.

For more on the rationale, you can check out this motivational slide deck (but on the very explicit understanding that the proposed UX changes therein are for illustrative purposes only, and final UX is still in development).

This will be a significant refactor with lots of UI touchpoints potentially affected, so I'm filing a meta-bug to track all the moving parts. Broadly, we'll know that we've succeeded when:

  • The "Join Firefox" flow from about:welcome allows users to set up their Firefox Account without enabling Sync
  • The "Sign up to Monitor" button on about:protections can sign users in to Firefox and display their Monitor report without enabling Sync
  • Users can easily enable Sync after the fact when they sign in via one of those flows.

[1] Note that "Signing in to Firefox" refers to credentials held by the Browser itself for its own use; it's entirely different from signing in to accounts.firefox.com on the Web, and we are not planning to conflate the two.

Depends on: 1570568
Depends on: 1570567
Depends on: 1570569

From initial discussions, I believe we have the following major states to consider:

  1. The user is not signed in to Firefox

    • The call-to-action in any UI touchpoints that involve an account needs to be about signing in
  2. The user is signed in to Firefox but has not verified their account or session

    • No account-related services work in this state
    • The call-to-action in any UI touchpoints that involve an account needs to be about verifying the account
  3. The user is signed in to Firefox, but their session is invalid/expired/etc

    • No account-related services work in this state
    • The call-to-action in any UI touchpoints that involve an account needs to drive the user to reconnect their account
  4. The user is signed in to Firefox with a valid session

    • The happy state!
    • Users in this state can send tabs to other devices connected to their account
    • Other Account-related features and services can do what they're designed to do (if the user activates them)
      • Individual UI touchpoints may offer toggles or other options to enable/disable particular features.

I've added a few dependant bugs to reflect the big pieces of UI that will need to update to reflect these various states. Ana, Ryan, what have I missed?

Flags: needinfo?(rfeeley)
Flags: needinfo?(amedinac)
Alias: fxa-desktop-decouple
Depends on: 1565960
Depends on: 1500843
Depends on: 1570572
Depends on: 1571048

Ryan and Leif, will we need a new way in FxA telemetry to track an active account if the user has Sync turned off in Firefox? If so, I'll file a bug for that too. Or would cert_signed still get triggered?

Flags: needinfo?(rfkelly)
Flags: needinfo?(loines)

will we need a new way in FxA telemetry to track an active account if the user has Sync turned off in Firefox?

I don't think so. Even if the user is signed in but not using any account-related services, there should still be some amount of background activity as the browser checks for e.g. updated profile picture or display name. This will generate cert_signed events and also some OAuth-related events that we can use to measure active accounts.

(We should definitely confirm that this all still works as part of shipping the feature, but I don't expect it to require significant new engineering work).

Flags: needinfo?(rfkelly)
Flags: needinfo?(loines)
Depends on: 1571526
Depends on: 1571584
Depends on: 1572313
No longer depends on: 1500843
Depends on: 1572344
Depends on: 1575704
Depends on: 1575921
Depends on: 1577662
Depends on: 1577690
Depends on: 1578632
No longer depends on: 1572344
Depends on: 1572212
Depends on: 1580342
Depends on: 1580383
Depends on: 1581707
Depends on: 1581709
Depends on: 1581980
Depends on: 1581982
No longer depends on: 1571526
Depends on: 1582002
Depends on: 1582023
Depends on: 1238810
Depends on: 1582253
Depends on: 1582263
Depends on: 1582633
Depends on: 1346334
Depends on: 1583413
Depends on: 1583414
Depends on: 1584249
Depends on: 1584258
Depends on: 1584287
Depends on: 1584293
Depends on: 1585426
Depends on: 1585428
No longer depends on: 1572313
No longer depends on: 1578632
No longer depends on: 1584249
Depends on: 1587450
Depends on: 1587837
Regressions: 1587837
No longer regressions: 1587837

Cross-linking for easy reference: Bug 1585724 is a follow-up bug for work related to this effort, but that is not critical to the success of this metabug.

See Also: → 1585724
Depends on: 1593353
Depends on: 1590231
No longer depends on: 1593353
Depends on: 1597961
Depends on: 1598314
See Also: → 1602000
You need to log in before you can comment on or make changes to this bug.