Remove NOTIFICATION_SESSION_STARTED from AccessibilityManager
Previously, this code used NOTIFICATION_SESSION_STARTED for initial login, and then UserManager::SessionStateObserver::ActiveUserChanged for swapping between users. It should be possible just to always rely on ActiveUserChanged. If the profile isn't loaded yet (as with initial login), add a profile created observer. This should mean SetProfile gets called slightly earlier as SESSION_STARTED comes rather late. This seems like an improvement because SetProfile will not be delayed until after the post-login steps (e.g. when the profile picture is being chosen). ChromeUserManager is changed slightly, listening to NOTIFICATION_PROFILE_ADDED rather than NOTIFICATION_PROFILE_CREATED. For async profile creation, NOTIFICATION_PROFILE_ADDED comes after NOTIFICATION_PROFILE_CREATED, but for synchronous profile creation (e.g. the startup profile), it's inverted; in both cases the two notifications are sent synchronously, i.e. as part of the same task. To make sure the profile is both initialized and registered with ProfileManager by the time ProfileCreatedObservers get notified, ChromeUserManager should make use of NOTIFICATION_PROFILE_ADDED. Bug: 268984 Change-Id: I53c1793f2a14642fb1e4cd32066e2a57eeebd1a3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1769227 Commit-Queue: Evan Stade <estade@chromium.org> Reviewed-by:Dominic Mazzoni <dmazzoni@chromium.org> Reviewed-by:
Mihai Sardarescu <msarda@chromium.org> Reviewed-by:
Xiyuan Xia <xiyuan@chromium.org> Cr-Commit-Position: refs/heads/master@{#692231}
Showing
Please register or sign in to comment