GitLab

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}