Issue metadata
Sign in to add a comment
|
iOS page load fails with timeout when on Captive Portal network |
||||||||||||||||||||||
Issue descriptionWhen navigating to some secure websites, the Captive Portal interstitial is not displayed, but instead the request times out after 60 seconds. What steps will reproduce the problem? (1) Connect to an affected Captive Portal network(*) without establishing a network connection. (2) Navigate to https://cs.chromium.org or https://google.com What is the expected result? Captive Portal interstitial should be displayed. What happens instead? The request times out and displays the timeout error page as seen in the attached screenshot. (*) This is not reproducible on all Captive Portal implementations. It is reproducible with Comcast's "xfinitywifi" network.
,
Nov 17 2017
,
Nov 22 2017
I often witness this on Android or Mac too. Last time it was with Lufthansa airplane wifi. But there are many many such wifi networks. Is there a reason this bug is iOS specific? My work around is to open any http page, that makes the browser go to the Captive portal. This is frustrating to witness in my favorite browser, in 2017. Is it so hard to detect that we are behind captive portal?
,
Nov 30 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e4c94fbc84ecd3150c696bf819dc4aa33b105d3a commit e4c94fbc84ecd3150c696bf819dc4aa33b105d3a Author: Mike Dougherty <michaeldo@chromium.org> Date: Thu Nov 30 23:39:28 2017 Add Captive Portal Metrics Tab Helper. Users on a Captive Portal network without an internet connection may see an error interstitial or experience timeouts. These metrics will help to identify users in these scenarios. Bug: 783315, 785548 Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs Change-Id: I911b6d9a57a017d2827ee0feeb07d8721acfa849 Reviewed-on: https://chromium-review.googlesource.com/783694 Commit-Queue: Mike Dougherty <michaeldo@chromium.org> Reviewed-by: Mark Pearson <mpearson@chromium.org> Reviewed-by: Eugene But <eugenebut@chromium.org> Reviewed-by: Mike Dougherty <michaeldo@chromium.org> Cr-Commit-Position: refs/heads/master@{#520748} [modify] https://crrev.com/e4c94fbc84ecd3150c696bf819dc4aa33b105d3a/ios/chrome/browser/ssl/BUILD.gn [add] https://crrev.com/e4c94fbc84ecd3150c696bf819dc4aa33b105d3a/ios/chrome/browser/ssl/captive_portal_metrics.h [add] https://crrev.com/e4c94fbc84ecd3150c696bf819dc4aa33b105d3a/ios/chrome/browser/ssl/captive_portal_metrics_tab_helper.h [add] https://crrev.com/e4c94fbc84ecd3150c696bf819dc4aa33b105d3a/ios/chrome/browser/ssl/captive_portal_metrics_tab_helper.mm [modify] https://crrev.com/e4c94fbc84ecd3150c696bf819dc4aa33b105d3a/ios/chrome/browser/ssl/ios_ssl_error_handler.mm [modify] https://crrev.com/e4c94fbc84ecd3150c696bf819dc4aa33b105d3a/ios/chrome/browser/tabs/tab_helper_util.mm [modify] https://crrev.com/e4c94fbc84ecd3150c696bf819dc4aa33b105d3a/tools/metrics/histograms/histograms.xml
,
Dec 28 2017
Add follow up date to check logged metrics data.
,
Feb 1 2018
The NextAction date has arrived: 2018-02-01
,
Mar 2 2018
During Feb. 2018, 4.8 million requests (sent by 1.4 million users) that would have eventually failed with a timeout error were caused by the user being behind a captive portal. (The request is not said to have failed with a timeout because the captive portal check is done after just 8 seconds. This is to aid in producing better metrics since many users will not wait for the full timeout so doing the check at that time would produce a much smaller sample set.) This metric has been turned off behind the "kCaptivePortalMetrics" flag since we already learned how frequent it is in the field. The metrics will remain in order to perform additional metrics collection in the future. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by michaeldo@chromium.org
, Nov 15 2017