Wondering if this is some kind of auto-re issue, esp since it only happens for crosprqa4.com?

14:10:41: EULA is accepted:
[1026:1026:0823/141041.097042:VERBOSE1:wizard_controller.cc(1388)] Wizard screen exit code: EULA_ACCEPTED

14:10:48: Auto Enrollment State AUTO_ENROLLMENT_STATE_TRIGGER_ZERO_TOUCH is set:
[1026:1026:0823/141048.957153:VERBOSE1:auto_enrollment_controller.cc(732)] New auto-enrollment state: 6
[1026:1026:0823/141057.978619:VERBOSE1:enrollment_screen.cc(217)] Authenticating using attestation.
I *think* the "Enterprise enrollment" screen with the progress bar starts around 14:10:57 in the video.

The next thing that happens well into 14:11 in the video is the blank screen.

Timing-wise, this could correspond with:
[1026:1026:0823/141107.943260:INFO:remote_commands_service.cc(38)] Fetching remote commands.

Which I think means that DeviceCloudPolicyInitializer::EnrollmentCompleted got called.
It also corresponds with /var/log/messages, which shows:
2018-08-23T21:11:07.758427+00:00 INFO cryptohomed[1076]: InstallAttributes have been finalized.
2018-08-23T21:11:07.774854+00:00 INFO session_manager[992]: [INFO:policy_service.cc(189)] Attempting to install new policy key.
2018-08-23T21:11:07.792204+00:00 INFO session_manager[992]: [INFO:policy_service.cc(224)] Persisted policy key to disk.
2018-08-23T21:11:07.801876+00:00 INFO session_manager[992]: [INFO:policy_store.cc(89)] Persisted policy to disk, path: /var/lib/whitelist/policy.1

Suggesting that the actual enrollment did work in the auto-enrollment attempt (assuming a 7 hours offset between /var/log/messages timestamps and /var/log/chrome timestamps).

However, I only see
[1026:1026:0823/141555.088839:VERBOSE1:wizard_controller.cc(1388)] Wizard screen exit code: ENTERPRISE_ENROLLMENT_COMPLETED
much later in the logs.

What's also weird is that ESC shows the enrollment screen in the "broken state".

The usual flow should be:
EnrollmentScreen::OnDeviceEnrolled()
EnterpriseEnrollmentHelperImpl::GetDeviceAttributeUpdatePermission()
EnterpriseEnrollmentHelperImpl::OnDeviceAttributeUpdatePermission()
EnrollmentScreen::OnDeviceAttributeUpdatePermission
EnrollmentScreen::ShowEnrollmentStatusOnSuccess()
EnrollmentScreen::OnConfirmationClosed()
Finish(ScreenExitCode::ENTERPRISE_ENROLLMENT_COMPLETED)

I'm sure that Finish is not being called, I'm not sure if we even enter EnrollmentScreen::OnDeviceEnrolled(). Maybe enrollment returns an error after all, we end up in EnrollmentScreenHandler::ShowSigninScreen() as a fallback, and this shows a sign-in screen on the enrollment screen which for some reason is not being rendered.

I'll try to repro this locally.

+Igor in case he has ideas.
I have not been able to repro successfully yet but I'll give it another try.

Update: I was able to repro this locally, will work on a fix.
Interestingly, it does not repro on chrome-on-linux, but it does repro on a real Chrome OS device (kevin in my case).

Status update:
It seems that:
- EnrollmentScreenHandler::ShowAttestationBasedEnrollmentSuccessScreen gets called (which is good)
- oauth-enroll-step-abe-success does get displayed as a consequence
- however, its child oauth-enroll-abe-success-card is not displayed

Investigating why not.

BTW, when this happens, the device appears to have been enrolled successfully. Only the screen displayed is broken. As a workaround, a reboot should bring back the sign-in screen.

Issue 878967 has been merged into this issue.

Since Pavol is OOO for a month, I will take this.

From initial investigation, the bug appeared somewhere between versions
10832.0.0	69.0.3476.0 - good
and
10840.0.0	69.0.3479.0 - bad

I suspect https://chromium-review.googlesource.com/c/chromium/src/+/945994 broke it, but not sure. Anyway, I checked and the CL https://chromium-review.googlesource.com/c/chromium/src/+/1122875 fixes this problem. Assigning the issue to antrim@ (the owner of that CL) to merge back to 69 after that CL lands.

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

commit 70ae48b083129487c2d7b9276491a1794d3efcef
Author: Denis Kuznetsov <antrim@google.com>
Date: Wed Sep 12 14:52:14 2018

Use polymer slots in enrollment screens

This CL is intended to go be patched to M69, so fix can not change any
localized strings. As Polymer localization mechanism does not work with
html in localized values, the slot mechanism is used, and screen code
adjusts innerHtlm for element that is added into slot.

Propper change will be sent as a separate CL.

Bug:  877257 
Change-Id: Ibf4eb3f9b751a2f6bb34bf833d860b1cdbfb75e8
Reviewed-on: https://chromium-review.googlesource.com/1219749
Commit-Queue: Denis Kuznetsov <antrim@chromium.org>
Reviewed-by: Alexander Alekseev <alemate@chromium.org>
Cr-Commit-Position: refs/heads/master@{#590677}
[modify] https://crrev.com/70ae48b083129487c2d7b9276491a1794d3efcef/chrome/browser/resources/chromeos/login/enrollment_license_card.html
[modify] https://crrev.com/70ae48b083129487c2d7b9276491a1794d3efcef/chrome/browser/resources/chromeos/login/enterprise_card.css
[modify] https://crrev.com/70ae48b083129487c2d7b9276491a1794d3efcef/chrome/browser/resources/chromeos/login/enterprise_header.css
[modify] https://crrev.com/70ae48b083129487c2d7b9276491a1794d3efcef/chrome/browser/resources/chromeos/login/enterprise_header.html
[modify] https://crrev.com/70ae48b083129487c2d7b9276491a1794d3efcef/chrome/browser/resources/chromeos/login/enterprise_header.js
[modify] https://crrev.com/70ae48b083129487c2d7b9276491a1794d3efcef/chrome/browser/resources/chromeos/login/oobe_screen_oauth_enrollment.html
[modify] https://crrev.com/70ae48b083129487c2d7b9276491a1794d3efcef/chrome/browser/resources/chromeos/login/oobe_screen_oauth_enrollment.js

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

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

Your change meets the bar and is auto-approved for M70. Please go ahead and merge the CL to branch 3538 manually. Please contact 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

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

commit ca6408ca3452c7e7570d70316c2612f51cb61a20
Author: Denis Kuznetsov <antrim@google.com>
Date: Thu Sep 13 19:32:34 2018

Use polymer slots in enrollment screens

This CL is intended to go be patched to M69/M70, so fix can not
change any localized strings. As Polymer localization mechanism does
not work with html in localized values, the slot mechanism is used,
and screen code adjusts innerHtlm for element that is added into slot.

Propper change will be sent as a separate CL.

Bug:  877257 
Change-Id: Ibf4eb3f9b751a2f6bb34bf833d860b1cdbfb75e8
Reviewed-on: https://chromium-review.googlesource.com/1219749
Commit-Queue: Denis Kuznetsov <antrim@chromium.org>
Reviewed-by: Alexander Alekseev <alemate@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#590677}(cherry picked from commit 70ae48b083129487c2d7b9276491a1794d3efcef)
Reviewed-on: https://chromium-review.googlesource.com/1225510
Reviewed-by: Denis Kuznetsov <antrim@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#383}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/ca6408ca3452c7e7570d70316c2612f51cb61a20/chrome/browser/resources/chromeos/login/enrollment_license_card.html
[modify] https://crrev.com/ca6408ca3452c7e7570d70316c2612f51cb61a20/chrome/browser/resources/chromeos/login/enterprise_card.css
[modify] https://crrev.com/ca6408ca3452c7e7570d70316c2612f51cb61a20/chrome/browser/resources/chromeos/login/enterprise_header.css
[modify] https://crrev.com/ca6408ca3452c7e7570d70316c2612f51cb61a20/chrome/browser/resources/chromeos/login/enterprise_header.html
[modify] https://crrev.com/ca6408ca3452c7e7570d70316c2612f51cb61a20/chrome/browser/resources/chromeos/login/enterprise_header.js
[modify] https://crrev.com/ca6408ca3452c7e7570d70316c2612f51cb61a20/chrome/browser/resources/chromeos/login/oobe_screen_oauth_enrollment.html
[modify] https://crrev.com/ca6408ca3452c7e7570d70316c2612f51cb61a20/chrome/browser/resources/chromeos/login/oobe_screen_oauth_enrollment.js

Verified in M70/M71, when FRE is enabled, enrollment screen is shown as expected, there is no blank white screen.

Chrome OS: 11021.79.0, Chrome: 70.0.3538.107
Chrome OS: 11151.31.0, Chrome: 71.0.3578.54
Device: Nautilus