Hi there. Can you attach a net log to this bug the next time that happens?

To do that, navigate to chrome://net-export in your browser.

Thanks for the log. I assume that these public wifi networks have captive portals (e.g., after connecting to their wifi, you have to visit a page to login). Typically you get to the login page by navigating to an http:// site. An https:// site won't work. Can you try navigating to http://example.com once you connect to one of these networks?

I see that you have data saver mode on. I'm not very familiar with data saver but perhaps it's causing issues. Could you try disabling it and see if that helps you to get to the captive portal login?  

To disable data saver:
Open Chrome Settings
Scroll down to "Data Saver" in Advanced, and select "Off".

Okays I shall try ...thank you for replying and offering help

Hey I turned off data savings mode & tried the link you sent & it
worked...thank you very much

[->DataProxy, as this sounds like it may be a problem with the data proxy.  -Needs-Feedback, as from the discussion it sounds like the OP has responded fully.]

Josh: Do you still have the log?  It doesn't appear to be attached to the bug. 

Glad that worked for you, though it seems perhaps something is buggy. bengr@, how does one get to a captive portal login page when data saver is on?

Also note that I have the netlog. Email me if you need access.

Chrome should automatically fall off of the data reduction proxy when there's a captive portal. Something obviously is wrong. I'll take a look at the net log.

crimson.d.ace@gmail.com: Would you mind if I attached the net log to this bug?

I looked through the net log and while I see plenty of evidence that Chrome could not fetch the data reduction proxy's config, I see no evidence that it Chrome tried a config that was blocked by the captive portal.  When Chrome doesn't have a config, it does not (should not) try to use the data reduction proxy.

rdsmith@: Did you see something suspicious in the log, other than the DATA_REDUCTION_PROXY events that say connections to googleapis.com and to check.googlezip.net failed? The former is the proxy config fetch that I mentioned. The latter is a check that connecting to the proxy via HTTPS is allowed by the carrier.

I see. Then it sounds like data saver is unlikely to be the issue and was likely that the browser needed to navigate to an http:// page. crimson.d.ace@, can you try http://example.com again but this time with data-saver enabled? Thanks!

Hey guys thanks for all the help..
See now the thing is ..when I go to these public places and use their WiFi
...chrome doesn't automatically go to their website anymore. ..it won't
load at all or just go to Google ...the only way I can get to their Web
page is using http://example.com
Any thoughts or suggestions ?

This sounds suspiciously like  crbug.com/631312 

crimson.d.ace: Most captive portals will listen for http:// (but not https://) traffic and redirect you to their login page. As more and more sites default (via HSTS) to https://, there are fewer pages that will take you to the captive portal's login page. This is quite confusing. So, for now please navigate to http://example.com in those situations.

It seems that in the future Chrome needs to do a better job of guiding users to the captive portal page. Created  issue 642322  for that.

Marking this as WontFix since it's technically working.