Possibly HSTS-related? Don't know much about captive portal stuff, but maybe one of my colleagues can route it further..

sanaasaleh839@ Thanks for the issue.

As this issue is out of scope of triaging at TE end, adding 'TE-NeedsTriageHelp' label and requesting the appropriate teams to look into the issue and help in further triaging.

Thanks..

In your reproduction steps, in step 2 you describe "the URL shows up but the page is blank". What is the URL that you are trying to load when connected to this WLAN? When you say the page shows up blank, does any error appear (saying something like you are not connected to the internet, your connection is not private, or something else), or is it a completely white page? If it's a completely white page, can you attach a net-export log (instructions at https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details) from connecting to the WLAN described in step 1 and trying to connect to the URL in step 2?

If the homepage is www.google.com, I'd expect in step 2 that you'd see "Your connection is not private" instead of a blank page.

Do you have any DNS based ACLs set on your WLC that allow some traffic through before the user has authenticated with the portal? If so, that might be interfering with Chrome detecting the portal.

Have you had a chance to review the feedback from Comment #5? Without further details, we won't be able to investigate and potentially resolve this issue.

[sanaasaleh839]:  Could you respond to comment #5?

A similar failure was reported in the Chrome Help forum for Android.  An initial http://www.google.com request gets mapped by Chromes HSTS preload to https, the portal intercepts the google request and returns its http..index.html, which causes an http/https conflict.

Look here
  https://productforums.google.com/d/msg/chrome/fCU-TkUEIcc/wbHnTD02CQAJ

Hi, I have this issue on android and it is an HSTS related issue.
When Chrome is opened by the system because the device detects that he is blocked by a captive portal, the http://www.google.com is used as a start URL, whatever the default homepage set up. The because of HSTS, http is redirected to https BEFORE any http request is made. Then when the https request is made, my captive portal responds bu it is too late, the cert is not the good one and we have a ERR_CONNECTION_REFUSED error that is not bypassable.
I wish Chrome would make the http request to google.com before applying the HSTS policy.
Or maybe I'm wrong but I think this is what happens.`

Brice

I must add that when Chrome opens itself after the connection to the wifi, it requests www.google.com. Even when the homepage is defined to another website.
Brice

Following the installation of Chrome Canary (70.0.3510.0) and Chrome Dev (69.0.3497.9)
it's working on the first launch, before the browser knows about the HSTS policy of google.com.
When I browse google.com, then after reconnecting to the Wifi, captive portal is not working anymore.

Android version is 6.0.1 on SM-G900F

Thanks for the report, this looks like it's a Captive portal issue, in which case Chrome is working as intended, as the Captive Portal redirection is indistinguishable from a man in the middle attack on the HTTPS connection, and as you noticed, you are not allowed to reach sites that are HSTS preloaded (such as google.com) over HTTP. One way to force the redirect is to manually visit http://nevertls.com, since that site is not an HTTPS site, the redirection to the login page should succeed.

Chrome does try to detect captive portals and show a captive portal interstitial instead, but the detection is not perfect.

meacer: Can you take a look from the captive portal detection side? Feel free to WontFix if this is not a case we can detect reliably. Thanks!

I'm having difficulty understanding the scenarios described here, and I feel like there might be multiple issues at hand.

sanaasaleh839@gmail.com: Can you please clarify the questions in comment #5?

brice@miramont.fr: Can you please upload a video for the problems you are seeing? It'll help us better understand the problem. Chrome doesn't open http://www.google.com when it detects a captive portal, I believe Samsung devices do that.

Also, more information about the devices you are using would be helpful, in particular whether they have both Wi-Fi and cellular data. Thanks!

It's been mentioned elsewhere that this is Samsung misfeature.  I'll dig out the ref later if needed.  Someone tested with two smartphones and the problem only showed up on their Samsung.

I am the ref Larry mentioned.
I have a Unifi captive portal setup at home and we have several devices. The problem with the captive portal 'always' going to www.google.com ONLY occurs on the Samsung Galaxy S5 I have from work (note: I have changed the homepage to my own homepage so not google). All other devices (some Samsung, some other brand) all work fine and show the login page immediately.

The same happened when on vacation on the captive portal there.

At this point in time my best guess is that this is a problem specific to the Samsung Galaxy S5 series, same as mentioned in comment 11.

Niels (ni@) As your problem is a Samsung and portal config issue, see my comments on your Help Forum post
https://productforums.google.com/forum/#!topic/chrome/fCU-TkUEIcc

If someone sees how to fix this from the Chrome side, let us know.