This sounds pretty bad. stevenjb@ can you take a look?

Note that this is not device-specific and it still appears on R62 and R63.

Questions:
1. The bug is reported with Chrome 60, but later it suggests that it regressed between 61.0.3138.0 and 61.0.3142.0, please confirm?

2. Please elaborate on "Connect device to proxy network" (i.e. provide the exact steps taken).

By default we should not allow the use of shared proxies in a Guest session.

Being connected to a proxy certainly should not affect loading of the Settings UI.

I have not been able to reproduce this locally.

I set a bogus proxy and confirmed that www.google.com fails to load but the Settings UI loads normally.

Also, re-reading the description, it sounds like the system tray menu is what is actually blank?

Apologies for the confusion between Chrome 60 and 61.

The issue is in R61 onward, where the working version is R61.0.3138.0 and the observed regression was seen in R61.0.3142.0.

The issue also occurs in user sessions, so I've attached a screenshot which illustrates the issue.

Deleted: Screenshot 2017-09-12 at 11.01.51 AM.png 362 KB

	Screenshot 2017-09-12 at 11.01.51 AM.png 362 KB View Download

The 'Connecting...' text at the bottom of the page is odd. I'm guessing that is a generic web page or Web UI thing?

So it looks like this does describe the Settings UI, not the System Tray.

I'm still unclear what was done for step 1, 'Connect device to proxy network'.

The blank page is the settings page, not a generic web page. I've added another attachment that shows what the page normally looks like.

As for step 1, 'Connect device to proxy network', I used a physical Ethernet connection that is hooked up to our corporate network, which has an explicit proxy filter.

I'm not sure what the behavior is for a WiFi connection to an explicit proxy filter, but I know that the behavior works as intended without a proxy involved (Ethernet or WiFi).

Deleted: Screenshot 2017-09-12 at 1.30.18 PM.png 394 KB

	Screenshot 2017-09-12 at 1.30.18 PM.png 394 KB View Download

Perhaps the page is attempting to pull information from an external source before timing out (because proxy information is not set yet) and loading the other page elements?

I see that the Settings page loads fine once the proxy information has been set for the Ethernet connection that I was using.

I did some digging and the 'Connecting...' text is most likely IDS_LOAD_STATE_CONNECTING which is set here:
https://cs.chromium.org/chromium/src/chrome/browser/ui/tab_contents/core_tab_helper.cc?type=cs&q=IDS_LOAD_STATE_CONNECTING&sq=package:chromium&l=192

The question is, why is chrome://settings dependent on an external resource (And how do we figure out what exactly)?

+rsleevi@ - Any thoughts on how to debug this or who would be a good person to ask?

@stevenjb: Are you able to repro the problem locally? If so, looking at the Developer tools network panel might reveal the problem. Also, can you repro the same with other WebUI pages? Maybe the problem is more generic about handling chrome:// URLs when a proxy is used and not specific to Settings.

I can not reproduce this with a hotspot with no internet; it seems like it needs to be connected to a network requiring a proxy. I don't currently have an environment available for testing that.

I will probably need to wait until I am next in MTV to test this, which will not be for a few weeks.

cernekee@ - Can you or someone in MTV try to reproduce this:
1. Connect to a network requiring a proxy to be configured (but do not have the proxy configuration set up)
2. Open the Settings page

We are looking for a blank page with "Connecting..." at the bottom.

If we can reproduce that, we want to try the same with visiting chrome://bookmarks and chrome://history to see whether they have the same problem.

Also we want to look at the 'Network' tab of the developer tools (ctrl-shift-j) to see if that reveals anything (e.g. what requests are blocking).

casey.g.bowman@ - Does the reproduce every time Settings is opened (while the network proxy is not configured) or just the first time?

> Connect to a network requiring a proxy to be configured (but do not have the proxy configuration set up)

Unfortunately I do not have a setup like this, but Aashutosh or Maksim might.

> Also we want to look at the 'Network' tab of the developer tools (ctrl-shift-j) to see if that reveals anything (e.g. what requests are blocking).

Agreed, this is the first thing I would check if a request is hanging.

FWIW all of the URLs I see accessed from the M62 settings page start with chrome://settings/ or chrome://resources/ .  If I add iptables and ip6tables rules to block all traffic, the page still renders correctly.  Can we verify that the chrome:// URLs are never passed to a PAC script?

 Issue 756684  has been merged into this issue.

I reported the same issue with logs, https://bugs.chromium.org/p/chromium/issues/detail?id=756684#c1

The logs are unlikely to be helpful. What we need is a repro, specifically how to set up a state where this can be reproduced.

@13
Yes, the issue is reproduced every time the Settings page is loaded, so if the Settings window is closed/re-opened or the page is refreshed while a proxy is not configured, the behavior will persist.

@14
I checked out the network tab while the settings page was in the 'Connecting...' state and it seems that "css?family=Roboto" has the only pending operation, which fails with a connection timeout and the Settings page loads immediately.

Hmm, interesting. I wonder if this is related to issue 760751 ?

I am able to reproduce this, when connected to a network for which internet access is only through a proxy. If no proxy is set on the DUT all the network traffic  gets blocked.

I saw the following logs on the console window of developer tools (ctrl-shift-j), 

GET https://fonts.googleapis.com/css?family=Roboto net::ERR_CONNECTION_TIMED_OUT
polymer-extracted.js:784 [Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider marking event handler as 'passive' to make the page more responsive. See https://www.chromestatus.com/feature/5745543795965952
add @ polymer-extracted.js:784
_listen @ polymer-extracted.js:1159
listen @ polymer-extracted.js:454
_listenListeners @ polymer-extracted.js:443
_marshalBehavior @ polymer-extracted.js:4093
_marshalBehaviors @ polymer-micro-extracted.js:526
_initFeatures @ polymer-extracted.js:4086
__initialize @ polymer-micro-extracted.js:226
createdCallback @ polymer-micro-extracted.js:209
instanceTemplate @ polymer-mini-extracted.js:92
_stampTemplate @ polymer-mini-extracted.js:88
_initFeatures @ polymer-extracted.js:4081
__initialize @ polymer-micro-extracted.js:226
createdCallback @ polymer-micro-extracted.js:209
instanceTemplate @ polymer-mini-extracted.js:92
_stampTemplate @ polymer-mini-extracted.js:88
_initFeatures @ polymer-extracted.js:4081
__initialize @ polymer-micro-extracted.js:226
createdCallback @ polymer-micro-extracted.js:209
instanceTemplate @ polymer-mini-extracted.js:92
_stampTemplate @ polymer-mini-extracted.js:88
_initFeatures @ polymer-extracted.js:4081
__initialize @ polymer-micro-extracted.js:226
createdCallback @ polymer-micro-extracted.js:209
window.Polymer @ polymer-micro-extracted.js:54
(anonymous) @ crisper.js:632
polymer-extracted.js:784 [Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider marking event handler as 'passive' to make the page more responsive. See https://www.chromestatus.com/feature/5745543795965952

+ Developer console logs attached.

Deleted: settings-1505432983708.log 172 KB

settings-1505432983708.log 172 KB View Download

The "css?family=Roboto" request seems to be the only "https://..." request going out, while all the other requests are local "chrome://..." requests, interestingly.

I *think* this might be fixed with the fix for issue 760751. We were accessing fonts.googleapis.com/ from night_light_slider.html.

I cannot access issue 760751. Is the fix mentioned there already merged and included in the latest ChromeOS images? I'd be happy to pull one of the latest official images down to test it out and confirm.

The fix just landed here: https://chromium-review.googlesource.com/671464

It should be in Canary in a day or two.

aashutoshk@, can you try reproducing with a ToT build (post master@{#502740}) ?

I've tested today's official R63 image and I'm no longer reproducing the issue.

Chrome version: 63.0.3223.0
OS version: 9973.0.0 (Official Build) dev-channel squawks test

That's great, thanks!

+merge-request for  https://chromium-review.googlesource.com/671464 (associated with issue 760751)

bhthompson@ - I think this is a more critical symptom of the same root cause as issue 760751 so I would now really like to merge that tiny change to 61 and fix both issues. Please LMKWYT.

(Note: The fix for issue 760751 was already merged to 62, so this should be fixed there as well).

For further confirmation, I checked the latest image for R62 and I couldn't reproduce the issue there either. :)

Chrome version: 62.0.3202.31
OS version: 9901.28.0 (Official Build) dev-channel squawks test

Thank you, Casey for testing. Closing this as verified. 

stevenjb@ Is this critical for M61?

I think so, thus the merge request :)

Not being able to access Settings (which is required to change a Proxy configuration) when behind a Proxy is a pretty bad problem!

Approving merge to M61. please merge by noon today.

Merged to 61 in issue 760751 (same root cause).

blank with "Connecting..." while connected via proxy