Do not assume OobeUI is around when deleting AppLaunchController
Currently, AppLaunchController assumes that AppLaunchSplashScreenView, owned by OobeUI, is around during AppLaunchController destruction. Both AppLaunchController and OobeUI lifetime is controlled by LoginDisplayHost, but OobeUI is technically owned by login window (which gets created by LoginDisplayHost, and closed on LoginDisplayHost destruction). Whether AppLaunchController get deleted before or after AppLaunchSplashScreenView largely depends on how the login window is closed/destroyed - generally the window is destroyed asynchronously when LoginDisplayHost goes out of scope, in which case AppLaunchController is deleted before the splash screen view, but this does not seem to be guaranteed. For example, in AutoLaunchedNonKioskEnabledAppTest.NotLaunched test with mash enabled, oobe_ui gets deleted synchronously when ScopedKeepAlive owned by LoginDisplayHostCommon gets deleted (which happens before the AppLaunchController is deleted) - ScopedKeepAlive going out of scope causes MusClient to start closing all widgets. To work around this have AppLaunchSplashScreenView notify its delegate (i.e. AppLaunchController) when it gets deleted, so the delegate can stop referencing it when that happens. Technically, the linked bug could be fixed by ensuring that app launch controller is deleted before ScopedKeepAlive, but that seems more fragile, and it doesn't necessarily address all concerns (e.g. the case where login window is removed for a reason other than login display host destruction). NOTE: The same applies to the ArcKioskController and ArcKioskSplashScreenView. Bug: 838992 Change-Id: I9b31293e791c1f8980e780e69f6061f87a968095 Reviewed-on: https://chromium-review.googlesource.com/1041485Reviewed-by:Xiyuan Xia <xiyuan@chromium.org> Commit-Queue: Toni Barzic <tbarzic@chromium.org> Cr-Commit-Position: refs/heads/master@{#556181}
Showing
Please register or sign in to comment