Better handle existing browsers in BrowserStatusMonitor initialization
During initialization, BrowserStatusMonitor initializes its browser_tab_strip_tracker_, which creates insertion events for all existing web contents - on these events, BrowserStatusMonitor was updating associated app statuses, and started observing the web contents for navigation, but was not updating the browser windows kShelfIDKey window property (which should match the active web content's app ID). This property would get updated on the next navigation, but if the web contents navigation had already finished by the time BrowserStatusMonitor was created, the browser window kShelfIDKey would remain unset. For example, during user first run flow, Discovery app window gets launched before the user session changes to active state, and thus before the BrowserStatusMonitor creation, causing the linked bug. This updates BrowserStatusMonitor::OnTabInserted to update the browser window kShelfIDKey immediately, instead of waiting for navigation. This required BrowserStatusMonitor::Initialize() call to be removed from ChromeLauncherController's ctor to ChromeLauncherController::Init, after CreateBrowserShortcutLauncherItem(). Attempts to update the shelf ID window property before calling CreateBrowserShortcutLauncherItem() are hitting DCHECK in ChromeLauncherController::GetBrowserShortcutLauncherItemController(). BUG=1075940 Change-Id: I9fb8e404349c01d1998fb01b5d8133ff0afc105f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2223976Reviewed-by:Nancy Wang <nancylingwang@chromium.org> Reviewed-by:
Timothy Loh <timloh@chromium.org> Commit-Queue: Toni Baržić <tbarzic@chromium.org> Cr-Commit-Position: refs/heads/master@{#775308}
Showing
Please register or sign in to comment