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

Issue 883035 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

EasyUnlockServiceRegular is incorrectly instantiated 3 separate times

Project Member Reported by hansberry@chromium.org, Sep 11

Issue description

Once the user enters their password and Chrome enters the regular user session, EasyUnlockServiceRegular is created and accessed via EasyUnlockServiceFactory::GetForBrowserContext(content::BrowserContext* browser_context). Factories like this one are intended to only create one instance of the service in question, by keying on the provided |browser_context|.

Assuming the same |browser_context| is passed into EasyUnlockServiceFactory, only one EasyUnlockServiceRegular should be created. However, I have observed EasyUnlockServiceRegular being created 3 separate times in a regular user session. I am certain that the first 2 times it is instantiated, it should not be.

The first 2 times EasyUnlockServiceRegular is instantiated, it comes from these callsites: existing_user_controller.cc [1] and user_session_manager.cc [2]. If you look at both callsites, it seems clear that EasyUnlockServiceRegular should not be created, but rather EasyUnlockServiceSignin should be! See [1]: a SigninProfile is passed into the factory, but EasyUnlockServiceRegular is created instead of EasyUnlockServiceSignin. I don't understand why this is occurring; EasyUnlockServiceFactory explicitly checks if a profile is a SigninProfile [3], but for some reason that check is incorrectly returning false.

Sidenote: one consequence of this buggy behavior is that a SigninProfile is being passed into EasyUnlockServiceRegular. This Profile isn't associated with feature flags that the user/Finch has enabled or disabled, so base::FeatureList returns the default value of all flags. That means, for example, that in its first 2 instantiations, checking MultiDevice flags in EasyUnlockServiceRegular will always return false. 

Callsites [1] and [2] need to be more thoroughly investigated to determine what they doing wrong. Additionally, why are these callsites even running, if they're intended to be signin (i.e., before a regular user session) specific? 

As far as I know, this issue has existed in Smart Lock for a long time without causing any user-visible issues, and still doesn't. As such, I don't see it as a high-priority item right now.

1) https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/existing_user_controller.cc?q=chrome/browser/chromeos/login/existing_user_controller.cc&sq=package:chromium&g=0&l=182
2) https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/session/user_session_manager.cc?q=login/session/user_session_manager.cc&sq=package:chromium&dr&l=1861
3) https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/easy_unlock/easy_unlock_service_factory.cc?sq=package:chromium&dr=CSs&g=0&l=89

 
Cc: tengs@chromium.org sacomoto@chromium.org
Tim, do you have any insight into whether this has always been the case or if something has regressed?

Sign in to add a comment