Customer is of the position that a change in device behaviour from M52 is the cause, and as such should not need to engage their network vendor to assist.

Appears they are prompted at sign-in stage for proxy credentials, however after entering in correct credentials it briefly displays the "sign in to your Chromebook" dialog box (for up to three seconds), then disappears and goes back to previous screen. 

alemate@ was a change to OOBE introduced in 52 that may have caused this?
regardless, we should make sure that proxy is working well in new-OOBE.

@zalcorn can you please check on this and make sure it is fixed? And please reassign to the appropriate eng lead. 

Graham: Proxy-Auth is one of those things which hasn't been tested end-to-end and I would strongly encourage you to recommend to the customer not to use this. Even if basic connectivity works, its possible other parts of the system may break in unexpected ways. ( Search for : Hotlist-Enterprise-ProxyAuth )

Understood Royans, though to the customer it appears to have broken with an update and involving their third-party network contractors appears unnecessary expense.

I'm curious why they don't hit the issue over WiFi? Same proxy as I understand.

There are  issues logged for WiFi, 
https://bugs.chromium.org/p/chromium/issues/detail?id=255258
https://bugs.chromium.org/p/chromium/issues/detail?id=589268

On investigation wifi network is not using same auth-proxy.

@alemate @zalcorn, are you able to advise if this is indeed an OOBE regression we can address?

It appears the customer also has issues authenticating with the proxy when device is already signed-in, whereby the prompt for credentials only works on < M52.

@pkakasi for any input - SE working with this customer.

Cannot repro this internally.

Albert, are you aware of any OOBE changes to M52 that might have caused this? Doesn't look like Alexander has had a chance to look at it.
Increasing priority as it sounds like others could be hitting this.

Thanks for bumping up the priority zalcorn@.  alemate@ is slammed with other things and having this at Pri-2 pretty much guaranteed that this wasn't going to be seen.

Not sure what could have changed in 52 to cause this. stevenjb@ or snanda@ any ideas?

I don't have any ideas, I'm not actually particularly familiar with the authentication flow at this point. +xiyuan@ who may know more.

This kind of problem definitely makes for a good argument to have a more complete network settings UI available in oobe/login however.

I'll look at changes that were made in M52 today, but I cannot debug this right now as I don't have proxy auth network.

I remember that the last time I was debugging/updating proxy detection code, the event flow from shill was very unstable, so probably the order of events changed and this case became broken.

This is a long shot, so apologies, but pbond@ / bartfab@ - could anything have changed on the enterprise side? 

I believe, there were only three commits to chrome/browser/chromeos/net/ . Two renames and one refactoring of WiFi code ( https://codereview.chromium.org/1891633002 ).

I didn't find any significant changes in ./chrome/browser/chromeos/login/screens/* or ./chrome/browser/ui/webui/chromeos/login/* between M51 and M52.

So it looks like we need someone who has test network, to build test version of Chrome with debug logging of shill messages, and to debug what's wrong here.

Unfortunately I don't have test network right now.


PS: I remember that xiaoyinh@ was investigating similar issues with Captive Portal some time ago. So probably she remembers some details on how to debug chrome reaction to shill network detection events.

xiaoyinh@ can you investigate this one?

Re#21: Sure, I will investigate on this.

Seems to be the same root cause as crbug.com/255258
Proxy authentication data is saved in the webview context, but this data does not get propagated into the main context. https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/existing_user_controller.cc?rcl=0&l=121

So the authentication doesn't actually go through and GaiaScreenHandler::OnPortalDetectionCompleted keeps getting ProxyAuthRequired signals.

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

commit 9514fbd507c6ffb769209244dc083abfc7879a5b
Author: xiaoyinh <xiaoyinh@chromium.org>
Date: Thu Jan 19 22:07:04 2017

propagate proxy auth info into the browser context.

BUG= 658625 ,255258
TEST=Manual

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

[modify] https://crrev.com/9514fbd507c6ffb769209244dc083abfc7879a5b/chrome/browser/chromeos/login/existing_user_controller.cc

This bug requires manual review: We are only 11 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), gkihumba@(cros), bustamante@(desktop)

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

LGTM if there aren't any problems found in tonight's canary I'll approve for merge.

Approving for merge into M56

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

commit c0dbdfeeeded42a7a6e32c50e6a9d764abe5ccc8
Author: Xiaoyin Hu <xiaoyinh@chromium.org>
Date: Fri Jan 20 23:52:51 2017

[Merge to branch 2924]propagate proxy auth info into the browser context.

BUG= 658625 ,255258
TBR=xiyuan@chromium.org, nharper@chromium.org, alemate@chromium.org
TEST=Manual

Review-Url: https://codereview.chromium.org/2644713003
Cr-Commit-Position: refs/heads/master@{#444855}
(cherry picked from commit 9514fbd507c6ffb769209244dc083abfc7879a5b)

Review-Url: https://codereview.chromium.org/2647793004 .
Cr-Commit-Position: refs/branch-heads/2924@{#828}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/c0dbdfeeeded42a7a6e32c50e6a9d764abe5ccc8/chrome/browser/chromeos/login/existing_user_controller.cc

Can we close this as verified, if the end user is no longer seeing this issue. 

Bulk verify old fixed bugs...