If https://codereview.chromium.org/1928013004/ is actually the cause, then I suspect this affects all the way back to M52.

Yes, it looks like this is the cause:

[19035:19035:0822/150001:WARNING:device_management_service.cc(548)] Dmserver request failed, retrying in 10s.
[19035:19035:0822/150011:WARNING:user_cloud_policy_manager_chromeos.cc(409)] Timed out while waiting for the policy fetch. The session will start with the cached policy.

So I think the problem is that no DM request will fail in less than 30 seconds now (we try the request, then try after 10 secs, then try again after 20 seconds). This causes us to hit the 10 second limit specified in UserCloudPolicyManagerFactoryChromeOS (kInitialPolicyFetchTimeoutSeconds).

I also notice that if we have a bad proxy, we will wait 10 seconds before retrying with no proxy which will break signin if the proxy is misconfigured.

So I think a few fixes are needed here:

1) Don't retry policy fetches (change ShouldRetry() to not retry if we get a connection error with a policy fetch).
2) If retrying due to a broken proxy, don't delay for the next fetch.

Thanks for marking as high priority Drew.  This is a fairly bad regression.

Also, one important addition to the fixes you outlined: If the device has WiFi off and no ethernet (which was the case when we tried demo'ing this with the executives) which implies no network at all - we should not ever attempt to do anything on the network before logging the user immediately into the partition.

I don't think we need to explicitly detect that case, since the network attempt will fail within a few msecs if there are no networks configured. We can just attempt to access the server as we normally do, as long as we don't retry policy fetches as I describe in comment #3.

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

commit d3ff97fdea62ba0b09a06cf4f730f92b151a2c58
Author: hunyadym <hunyadym@chromium.org>
Date: Wed Aug 24 12:42:37 2016

Don't retry fetching policies if it's a blocking operation,
don't wait if we will bypass the proxy next time.

BUG= 639822 

Review-Url: https://codereview.chromium.org/2275553002
Cr-Commit-Position: refs/heads/master@{#414055}

[modify] https://crrev.com/d3ff97fdea62ba0b09a06cf4f730f92b151a2c58/components/policy/core/common/cloud/device_management_service.cc
[modify] https://crrev.com/d3ff97fdea62ba0b09a06cf4f730f92b151a2c58/components/policy/core/common/cloud/device_management_service.h
[modify] https://crrev.com/d3ff97fdea62ba0b09a06cf4f730f92b151a2c58/components/policy/core/common/cloud/device_management_service_unittest.cc

Do we want this fix to be merged back into M53?

I think we do want this merged back to M53 - Cyrus, can you drive this with the TPMs?

Yes Drew is 100% right.  We definitely need this merged.  It's a pretty bad regression.

I'm not sure what driving it with TPMs means.  Merge request has been filed on this, right?  I added a release block stable 53.

Also, Drew, can we find out why this wasn't caught by QA?  And do we not have automated tests to test offline login speed?  Has that been fixed?

Thanks!

No, there are no automated tests, and I suspect QA doesn't include this as part of their manual test pass. You might reach out to scunningham@ if we think this should be added to the manual test pass, but at this point everything we add to the manual test pass we need to remove something also.

Re: "drive with TPMs" - ping them to get it approved in a timely manner and explain why it's important to fix in M53 ; it's usually a nice courtesy when requesting a merge this late in the cycle. But I'm definitely not telling you how to do your business - happy to hang out and wait for Merge-Approved to magically show up.

Your change meets the bar and is auto-approved for M53 (branch: 2785)

Scott, can we get someone to verify this on canary on M54? Once we do that I can merge back to M53.

Tried in M54/Kip device/corp account.It still takes 12 sec for offline signin

M	ChromeOS	Chrome	ARC	Type	Channel
54	8743.0.0	54.0.2837.0	3223790	release	dev

54.0.2837.0 doesn't contain this change yet.

ok. This is the latest build available to test.

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

 Issue 641178  has been merged into this issue.

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

commit 6dd8afe748a248f5a30121d91b493c1261d9726f
Author: Andrew Wilson <atwilson@chromium.org>
Date: Mon Aug 29 13:13:51 2016

Don't retry fetching policies if it's a blocking operation, don't wait if we will bypass the proxy next time.

BUG= 639822 

Review-Url: https://codereview.chromium.org/2275553002
Cr-Commit-Position: refs/heads/master@{#414055}
(cherry picked from commit d3ff97fdea62ba0b09a06cf4f730f92b151a2c58)

Review URL: https://codereview.chromium.org/2285233002 .

Cr-Commit-Position: refs/branch-heads/2785@{#776}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/6dd8afe748a248f5a30121d91b493c1261d9726f/components/policy/core/common/cloud/device_management_service.cc
[modify] https://crrev.com/6dd8afe748a248f5a30121d91b493c1261d9726f/components/policy/core/common/cloud/device_management_service.h
[modify] https://crrev.com/6dd8afe748a248f5a30121d91b493c1261d9726f/components/policy/core/common/cloud/device_management_service_unittest.cc

Verified in M54(kip).

Approximate taking 2-4 seconds now.

M	ChromeOS	Chrome	ARC	Type	Channel
54	8743.3.0	54.0.2840.3	3226465	release	dev

Verified in M53/Kip
 
Columns
M	ChromeOS	Chrome	ARC	Type	Channel
53	8530.78.0	53.0.2785.93	3241884	release	beta