PrimaryAccountAccessTokenFetcher: Simplify observing of signin classes
PrimaryAccountAccessTokenFetcher currently has a very targeted observance of SigninManager and ProfileOAuth2TokenService: - It observes SigninManager during the duration of time from which it determines it needs to see a signin to when that signin occurs. - It observes PO2TS during the duration of time from which it determines that the user is signed in without a refresh token to when the refresh token becomes available. This targeted observance allows for having nice DCHECKs around exactly what state of waiting the token fetcher is in when given observer callbacks occur. However, we will shortly be porting this class to talk to IdentityManager. After the porting, it will no longer be possible to maintain this targeted observance, as by design IdentityManager::Observer folds the functionality of SigninManagerBase::Observer and OAuth2TokenService::Observer together. Thus, for example, if the token fetcher is obstensibly waiting for a refresh token to become available, it might in fact see the user sign in again (if they managed to sign out and sign back in in the interim, for example). This CL changes PrimaryAccountAccessTokenFetcher in anticipation of that porting: - It starts observing SigninManager and PO2TS immediately when launching in WaitUntilAvailable mode via ScopedObserver instances if credentials are not immediately available. - When it starts an access token request, it removes these observers if they are present (in addition to not being present if launched in RequestImmediately mode, access token requests get retried once by the fetcher in WaitUntilAvailable mode; thus, it's not guaranteed that these observers will be present at the time of starting an access token request). - Otherwise, the observers are removed implicitly on destruction. A side effect of these changes is that the nice DCHECKs mentioned above must necessarily be removed. In fact, there could be behavioral changes; e.g., PrimaryAccountAccessTokenFetcher could observe a signin event where it hadn't before in the case mentioned above. However, these behavioral changes are harmless, as PrimaryAccountAccessTokenFetcher's observer callback implementations are essentially stateless: they simply wait for the moment when both the primary account info and the refresh token for that account are available, and then synchronously fire off an access token request and stop listening for further signin events. Observing more signin-related events will simply result in more checks for whether that moment has arrived. Bug: 796544 Change-Id: I58738bb697e38008012f7b8bc759ed8c8382c516 Reviewed-on: https://chromium-review.googlesource.com/1092575 Commit-Queue: Colin Blundell <blundell@chromium.org> Reviewed-by:Marc Treib <treib@chromium.org> Cr-Commit-Position: refs/heads/master@{#566023}
Showing
Please register or sign in to comment