to poromov: who could verify this bug?

I'm looking into it. Can't reproduce on latest M71 build - maybe it was fixed later.

Can't reproduce on the same M70-11021.28.0 build as well. Auto-launched kiosk app start can be interrupted within 3 seconds by pressing CTRL+ALT+S. Yes, it should be done pretty fast, but it's possible.

Andres, could you please also verify that it works? I think this should've been already tested as a part of QA verification for the build.

I just moved a device to Dev Channel with 71.0.3558.0.

CTRL+ALT+S does not work to bypass the kiosk app.

When the normal phase that you can bypass the kiosk app happens, there is a toast at the bottom of the screen to power off, browse as guest, or add person. *These are based on policy settings so they won't be the same for everyone.

The screen goes by so quickly there is no reason to expect a mouse click to happen. If you are successful with the mouse click it still will not bypass the kiosk app.

I have attached a video showing the new toast at the bottom I am seeing. While this toast was at the bottom I was repeatedly pressing CTLR+ALT+S in a way that would work in previous versions.

Deleted: WP_20181002_10_20_13_Pro.mp4 26.6 MB

WP_20181002_10_20_13_Pro.mp4 26.6 MB Download

Quan, the behavior here looks interesting and I'm assuming it could be related to login UI changes.
It looks like AppLaunchController starts "timer" and requests to show splash screen [1] (around second 7-8 on the video), but showing the splash screen itself takes more than 3 seconds (min time for which it's shown), so after that it immediately starts app here [2].

[1] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/app_launch_controller.cc?l=182&rcl=0a36ad98fc438ecf2ba85e62127e54d34039e51c
[2] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/app_launch_controller.cc?l=510&rcl=0a36ad98fc438ecf2ba85e62127e54d34039e51c

Do you have ideas why showing splash screen might now take longer? Is there any signal that it might listen to to ensure that it's loaded and shown?

Otherwise, the simple solution might be to increase the min time for which it's shown from 3sec, but I prefer to avoid it as it really depends on performance of the device.

The loading application window is no longer view-able either, so the above does make sense to me.

the black screen is new with this release, previous releases were a smooth transition to the application loading screen without the video driver resetting.. or other cause for the black screen that appears.

In the new login UI, the splash screen is hosted in a webui modal that gets fullscreened when an app launches [1]. I think that's the main difference between this version of the login screen and the previous one. In the new version the CTRL+ALT+S shortcut is forwarded to the webui which handles it.

Anyway, looking at the timing code for the splash screen I don't think there's a great way to really enforce that the splash screen *actually* shows for three seconds, beyond the best effort that it does now. I think a potential solution might be to check if the splash screen page is ready (to accept JS calls), and if not, we just kill the app load from the C++ code. This hinges on us being able to actually query for the page state but I think (?) this is supported. CC-ing jdufault@ to confirm whether this is possible.

[1] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/ui/login_display_host_mojo.cc?l=228

I filed a similar bug to this back in august 31. crbug.com/879652

[11021.28.0]The behavior I am noticing this time around is the user is able to cancel the first auto launch of the kiosk application after enrollment. Once the user reboots the device the splash screen will not show up and the kiosk application will immediately launch.

I am also noticing this behavior on 11125.0.0, 71.0.3567.0

Deleted: debug-logs_20181004-102505.tgz 338 KB

debug-logs_20181004-102505.tgz 338 KB Download

Inside the admin panel, I changed the application that was set to auto launch to a different application. I waited a couple of minutes before rebooting the device. After reboot the device lands in the sign in screen and will not launch the application.

Attaching logs

Deleted: debug-logs_20181004-111734.tgz 474 KB

debug-logs_20181004-111734.tgz 474 KB Download

Deleted: kiosk_launch_error.jpg 839 KB

	kiosk_launch_error.jpg 839 KB View Download

cc'ing jdufault@ per comment #8

Meantime I'm going to temporary increase min time for which the screen is "shown" from 3 to 10 seconds - it should be enough as even on slowest devices it takes ~3-4 seconds to show it.

On webui login (m69) we don't signal a ready state until the webui has loaded. On views login (m70) we signal the ready state when views is ready but the webui may still be loading.

My guess is that timer needs to wait until the webui is ready, then show the splash screen.

qnnguyen@, I think it makes sense to split kiosk off into it's own webui as well, so that we don't need to worry about the load time.

I just wanted to show you both R70 and R69 loading into kiosk mode side by side.

R70 is on the left
R69 is on the right.

Deleted: R70csR69Kiosk.mp4 21.8 MB

R70csR69Kiosk.mp4 21.8 MB Download

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

commit fe45d4757c0f4dc339c6a0b4e79aaf7a99c122a3
Author: Sergey Poromov <poromov@chromium.org>
Date: Fri Oct 05 20:15:53 2018

Increase kiosk splash screen min time.

Increasing from 3 to 10 seconds as it now takes around
3 seconds to show the screen on the slow devices.
This is an easy temporary fix.
Perfectly, controller should start timer only when
splash screen is actually shown.

Bug:  890368 

Change-Id: I2048a54c1df7f2474cc29eb1d00e06bac3ff1e7f
Reviewed-on: https://chromium-review.googlesource.com/c/1264635
Reviewed-by: Jacob Dufault <jdufault@chromium.org>
Commit-Queue: Sergey Poromov <poromov@chromium.org>
Cr-Commit-Position: refs/heads/master@{#597265}
[modify] https://crrev.com/fe45d4757c0f4dc339c6a0b4e79aaf7a99c122a3/chrome/browser/chromeos/login/app_launch_controller.cc
[modify] https://crrev.com/fe45d4757c0f4dc339c6a0b4e79aaf7a99c122a3/chrome/browser/chromeos/login/arc_kiosk_controller.cc

Assigning to Quan to make the proper fix per comment #14.

Also requesting merge into M70 for temporary fix Cl from comment #16.

This bug requires manual review: We are only 6 days from stable.
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

verified fixed on M71 71.0.3572.0. Will verify once more when it lands on M70.

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

commit b6f09861adf7e5c72a4898500ea83a4cf3e13608
Author: Sergey Poromov <poromov@chromium.org>
Date: Thu Oct 11 14:11:36 2018

Increase kiosk splash screen min time.

Increasing from 3 to 10 seconds as it now takes around
3 seconds to show the screen on the slow devices.
This is an easy temporary fix.
Perfectly, controller should start timer only when
splash screen is actually shown.

Bug:  890368 

Change-Id: I2048a54c1df7f2474cc29eb1d00e06bac3ff1e7f
Reviewed-on: https://chromium-review.googlesource.com/c/1264635
Reviewed-by: Jacob Dufault <jdufault@chromium.org>
Commit-Queue: Sergey Poromov <poromov@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#597265}(cherry picked from commit fe45d4757c0f4dc339c6a0b4e79aaf7a99c122a3)
Reviewed-on: https://chromium-review.googlesource.com/c/1270738
Reviewed-by: Sergey Poromov <poromov@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#959}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/b6f09861adf7e5c72a4898500ea83a4cf3e13608/chrome/browser/chromeos/login/app_launch_controller.cc
[modify] https://crrev.com/b6f09861adf7e5c72a4898500ea83a4cf3e13608/chrome/browser/chromeos/login/arc_kiosk_controller.cc

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

Commit: b6f09861adf7e5c72a4898500ea83a4cf3e13608
Author: poromov@chromium.org
Commiter: poromov@chromium.org
Date: 2018-10-11 14:11:36 +0000 UTC

Increase kiosk splash screen min time.

Increasing from 3 to 10 seconds as it now takes around
3 seconds to show the screen on the slow devices.
This is an easy temporary fix.
Perfectly, controller should start timer only when
splash screen is actually shown.

Bug:  890368 

Change-Id: I2048a54c1df7f2474cc29eb1d00e06bac3ff1e7f
Reviewed-on: https://chromium-review.googlesource.com/c/1264635
Reviewed-by: Jacob Dufault <jdufault@chromium.org>
Commit-Queue: Sergey Poromov <poromov@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#597265}(cherry picked from commit fe45d4757c0f4dc339c6a0b4e79aaf7a99c122a3)
Reviewed-on: https://chromium-review.googlesource.com/c/1270738
Reviewed-by: Sergey Poromov <poromov@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#959}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}

still seeing this on M70 Beta 11021.45.0, 70.0.3538.58.

issue is still present on Chrome OS 11021.51.0, 70.0.3538.69. Is this fix getting merged to M70 stable?

I can consistently cancel the kiosk app launch on 70.0.3538.69

- directly boot, kiosk auto-launches, cancel works
- enter public session, exit, kiosk auto-launches, cancel works

Can you record a video of it failing?

Still seeing issue present in m70 see above. 

The transition to the blue screen at the end is the app loading, with no prompt to bypass kiosk mode. CTRL+ALT+S does not interrupt by pressing during the entire boot process.

I am also considering opening another bug, as it does not appear permissions in the manifest are being loaded before app launch either. This will be hard to demonstrate.. but there is a permission in this apps manifest to allow webview that is not taking effect. Demonstrated by the blue screen and the app not loading correctly.

The change was merged AFTER 70.0.3538.58 version. Any version newer (e.g. Chrome OS 11021.46.0+, Chrome 70.0.3538.63+) has it.
So, the old behavior is #24 and #27 is expected.

Confirmed.

Marking a P2 since we have a workaround in place.

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time.
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Thursday, 01/17/19 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.