New issue
Advanced search Search tips

Issue 838992 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: May 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

"AutoLaunchedNonKioskEnabledAppTest.NotLaunched" is flaky

Project Member Reported by chromium...@appspot.gserviceaccount.com, May 2 2018

Issue description

"AutoLaunchedNonKioskEnabledAppTest.NotLaunched" is flaky.

This issue was created automatically by the chromium-try-flakes app. Please find the right owner to fix the respective test/step and assign this issue to them. If the step/test is infrastructure-related, please add Infra-Troopers label and change issue status to Untriaged. When done, please remove the issue from Sheriff Bug Queue by removing the Sheriff-Chromium label.

We have detected 3 recent flakes. List of all flakes can be found at https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyOQsSBUZsYWtlIi5BdXRvTGF1bmNoZWROb25LaW9za0VuYWJsZWRBcHBUZXN0Lk5vdExhdW5jaGVkDA.

Flaky tests should be disabled within 30 minutes unless culprit CL is found and reverted. Please see more details here: https://sites.google.com/a/chromium.org/dev/developers/tree-sheriffs/sheriffing-bug-queues#triaging-auto-filed-flakiness-bugs
 
Owner: tbarzic@chromium.org
Status: Assigned (was: Untriaged)
Please disable this test soon if there is no simple fix
Status: Started (was: Assigned)
I'll disable the test while I'm investigating this:
https://chromium-review.googlesource.com/c/chromium/src/+/1040786
Project Member

Comment 4 by bugdroid1@chromium.org, May 2 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b22dd386ea39c8b4294a0a9c974c8d6dd7f21c70

commit b22dd386ea39c8b4294a0a9c974c8d6dd7f21c70
Author: Toni Barzic <tbarzic@chromium.org>
Date: Wed May 02 22:31:11 2018

Disable AutoLaunchedNonKioskEnabledAppTest.NotLaunched

Disabling flaky AutoLaunchedNonKioskEnabledAppTest.NotLaunched test
while I investigate it.

BUG= 838992 

Change-Id: I34f7f6c0f37ab08f6efa7ba087b8c18e7c11c408
Reviewed-on: https://chromium-review.googlesource.com/1040786
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Commit-Queue: Toni Barzic <tbarzic@chromium.org>
Cr-Commit-Position: refs/heads/master@{#555581}
[modify] https://crrev.com/b22dd386ea39c8b4294a0a9c974c8d6dd7f21c70/chrome/browser/chromeos/login/auto_launched_kiosk_browsertest.cc

Comment 5 by treib@chromium.org, May 3 2018

Labels: -Sheriff-Chromium Test-Disabled AutoLaunchedNonKioskEnabledAppTest.NotLaunched OS-Chrome
Project Member

Comment 6 by bugdroid1@chromium.org, May 4 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/10c40a353ec526f8738fbf490509fdac5f19c16d

commit 10c40a353ec526f8738fbf490509fdac5f19c16d
Author: Toni Barzic <tbarzic@chromium.org>
Date: Fri May 04 20:43:23 2018

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/1041485
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Commit-Queue: Toni Barzic <tbarzic@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556181}
[modify] https://crrev.com/10c40a353ec526f8738fbf490509fdac5f19c16d/chrome/browser/chromeos/login/app_launch_controller.cc
[modify] https://crrev.com/10c40a353ec526f8738fbf490509fdac5f19c16d/chrome/browser/chromeos/login/app_launch_controller.h
[modify] https://crrev.com/10c40a353ec526f8738fbf490509fdac5f19c16d/chrome/browser/chromeos/login/arc_kiosk_controller.cc
[modify] https://crrev.com/10c40a353ec526f8738fbf490509fdac5f19c16d/chrome/browser/chromeos/login/arc_kiosk_controller.h
[modify] https://crrev.com/10c40a353ec526f8738fbf490509fdac5f19c16d/chrome/browser/chromeos/login/auto_launched_kiosk_browsertest.cc
[modify] https://crrev.com/10c40a353ec526f8738fbf490509fdac5f19c16d/chrome/browser/chromeos/login/screens/app_launch_splash_screen_view.h
[modify] https://crrev.com/10c40a353ec526f8738fbf490509fdac5f19c16d/chrome/browser/chromeos/login/screens/arc_kiosk_splash_screen_view.h
[modify] https://crrev.com/10c40a353ec526f8738fbf490509fdac5f19c16d/chrome/browser/ui/webui/chromeos/login/app_launch_splash_screen_handler.cc
[modify] https://crrev.com/10c40a353ec526f8738fbf490509fdac5f19c16d/chrome/browser/ui/webui/chromeos/login/arc_kiosk_splash_screen_handler.cc

Status: Fixed (was: Started)

Sign in to add a comment