New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 879493 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 881302
Owner:
Closed: Sep 26
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Decide whether we want features to observe the bridge to get Sync state, or sync service

Project Member Reported by feuunk@google.com, Aug 31

Issue description

Some features (like Wallet) need to know the current syncing account, and whether or not the user has full sync enabled.

We have roughly 2 options:
1. They can observe ProfileSyncService, which already exposes this state.
Pro: This already exists, and lives on the main thread, where most features likely need it.
Con: ProfileSyncService contains the *global* sync state across the profile. Since with USS, we already tell the feature which state we're in through the bridge, it would be cleaner if features could just use that.
Con: ProfileSyncService is already exposing too much state, would be nice to cut that down.

2. Features can observer their bridge to learn what the sync state is.
Pro: This is a very localized call, and supports future scenarios where different features have different states.
Con: For some features (like autofill, Payments), the bridge runs on the DB thread, while both the Sync state and the feature are on the main thread. This causes a lot of thread hopping, with potential for race conditions.
 
Mergedinto: 881302
Status: Duplicate (was: Assigned)
This will be addressed in crbug.com/881302

Sign in to add a comment