I confirmed the issue began in M68.0.3438.0 10710.0.0 dev.  No issue in earlier builds.

Also reproduced in M69.0.3451.0 10757.0.0 dev where the provider login form was not even displayed in the dialog.

My steps were just installing the build and signed in with SSO account using Okta provider.

Jacob, could this be an issue with the new login UI?

xiaoyinh@, can you take a look?

Re#4: Sure, looking now.

Looks like this regressed between chrome version 68.0.3437.0 to M68.0.3438.0.

I did a bisect and found the culprit CL: https://chromium-review.googlesource.com/c/chromium/src/+/1055470

first bad commit: [0d7d74584f957455326b334f3476be4720b70353] Surface synchronization: Remove content_source_id in VisualProperties

+ Code author: Fady, could you help to triage?

Are there repro steps I can use to try to debug this locally?

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

commit 17a31897605229278ff39159d804253f10c11567
Author: Fady Samuel <fsamuel@chromium.org>
Date: Tue Jun 12 01:38:59 2018

Surface synchronization: Fix OOPIF resize

Allocating LocalSurfaceIds is an asynchronous process for OOPIFs because
they have to happen in the parent renderer. The first VisualProperties
object shipped to the child renderer has an invalid LocalSurfaceId which
suspends commits when surface synchronization is enabled.

For OOPIFs, we previously forced a new SynchronizeVisualProperties
push for OOPIF navigation which set the |visual_properties_pending_ack_|
on the browser side. This forced push meant that if nothing is changing renderer-side
then and ACK will not be sent back. This could cause a hang of renderer-resizes/visual
properties updates.

The reason we forced a push is a workaround for another bug. At some point, we pushed
a SynchronizeVisualProperties and set the pending bit, but we never got back an ACK.
We should only set the pending bit if the size has changed AND we have a valid
LocalSurfaceId.

Change-Id: Icd2baee36d6ebef3f7108b207821ef414a8e8a88
Bug:  672962 ,  850203 
Reviewed-on: https://chromium-review.googlesource.com/1095417
Commit-Queue: Fady Samuel <fsamuel@chromium.org>
Reviewed-by: Saman Sami <samans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#566230}
[modify] https://crrev.com/17a31897605229278ff39159d804253f10c11567/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/17a31897605229278ff39159d804253f10c11567/content/browser/renderer_host/render_widget_host_unittest.cc
[modify] https://crrev.com/17a31897605229278ff39159d804253f10c11567/content/browser/renderer_host/render_widget_host_view_child_frame.cc

Thanks fsamuel@ - can you please confirm if this is verified in canary?

This bug requires manual review: M68 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

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

Verified the issue has been fixed in ChromeOS 10718.21.0 M68.0.3440.23 canary kevin as tested on single user SAML sign-in as well as Enterprise enrollment.

Approving merge for M68. Branch:3440

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

commit 9281f4c88dd2e8c7c7f0d79366a90d3a0a9d4dc5
Author: Fady Samuel <fsamuel@chromium.org>
Date: Wed Jun 13 17:55:41 2018

Surface synchronization: Fix OOPIF resize

Allocating LocalSurfaceIds is an asynchronous process for OOPIFs because
they have to happen in the parent renderer. The first VisualProperties
object shipped to the child renderer has an invalid LocalSurfaceId which
suspends commits when surface synchronization is enabled.

For OOPIFs, we previously forced a new SynchronizeVisualProperties
push for OOPIF navigation which set the |visual_properties_pending_ack_|
on the browser side. This forced push meant that if nothing is changing renderer-side
then and ACK will not be sent back. This could cause a hang of renderer-resizes/visual
properties updates.

The reason we forced a push is a workaround for another bug. At some point, we pushed
a SynchronizeVisualProperties and set the pending bit, but we never got back an ACK.
We should only set the pending bit if the size has changed AND we have a valid
LocalSurfaceId.

Change-Id: Icd2baee36d6ebef3f7108b207821ef414a8e8a88
Bug:  672962 ,  850203 
Reviewed-on: https://chromium-review.googlesource.com/1095417
Commit-Queue: Fady Samuel <fsamuel@chromium.org>
Reviewed-by: Saman Sami <samans@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#566230}(cherry picked from commit 17a31897605229278ff39159d804253f10c11567)
Reviewed-on: https://chromium-review.googlesource.com/1099515
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#335}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/9281f4c88dd2e8c7c7f0d79366a90d3a0a9d4dc5/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/9281f4c88dd2e8c7c7f0d79366a90d3a0a9d4dc5/content/browser/renderer_host/render_widget_host_unittest.cc
[modify] https://crrev.com/9281f4c88dd2e8c7c7f0d79366a90d3a0a9d4dc5/content/browser/renderer_host/render_widget_host_view_child_frame.cc

Issue 850059 has been merged into this issue.

This has been merged back into M68.

Hi there. Maybe this is expected with how the Chrome OS branching strategy works (not too familiar with it yet), but I think I'm still hitting this issue on the latest dev build that just got installed:

10718.22.0 (Official Build) dev-channel eve

In my case I'm trying to log in to my account with Okta. Basically I can't click on anything inside the Okta frame. It's also interesting that the background image doesn't fully load. It's like the whole frame is frozen. I can log in to the same Google account with a different chromebook running the latest Stable release.

Is this a different issue, or do I just need to wait for a later dev channel release?

Thanks

It's not live on beta yet. Should be there from 68.0.3440.26 version of Chrome

This has been in beta for a while now. I'm marking as FIXED. Please reopen if this is still an issue.

Verified this in M68 (10718.36.0, 68.0.3440.45) and M69 (10827.0.0, 69.0.3475.0) using Okta, user can type in SAML login dialog without any issues. Please reopen if you still have this problem.