[GitHub issue by tonychung on 2012-05-08T17:24:05Z, https://github.com/mozilla-b2g/gaia/issues/1361] When connecting to a network that requires captive portal sign-in, the popup dialog does not get triggered automatically. Instead, the page just launches a Server Not Found error, with no further instructions. Repro 1) nexus S, Gaia commit: 2012-05-04 22:41: 20430a3cb36dbdcc..... 2) connect to a SSID that requires a captive portal dialog signin (Corporate site like QCOM, coffee shop, etc..) 3) Verify first that your network is connected via Wifi settings "Connected to _____" 4) knowing this SSID requires captive portal sign in, go and launch browser 5) type in any site to try and trigger the expected captive portal. 6) Verify no captive portal auto re-direct site is opened. Instead, just a 404 error. Expected: - a captive portal dialog should appear in SSID's like coffee shops and corporate sites, etc.. Not showing anything but a Server not Found is bad. Actual; - no captive portal dialogs
[GitHub comment by fabi1cazenave on 2012-05-14T07:15:36Z] By «expected» I guess you mean «iPhone-parity»? Neither my laptop nor the Android devices I played with have such a behavior: the login/password is asked when the browser is started and the connection isn’t started until then. The iOS behavior might be possible to implement. All I can think at the moment would be to ping a fixed IP and see if that causes an http redirection… Would that be an acceptable method, or is that too hackish?
[GitHub comment by asutherland on 2012-05-14T20:49:10Z] @clarkbw implemented captive portal detection logic for Thunderbird: https://github.com/clarkbw/Thunderbird-Captive-Portal-Detector I believe it basically just hits a known URL and checks for a redirect. It is my understanding from clarkbw from his investigation that this is how Windows does it. I do recall some mention of potentially checking the contents of the file for a known byte string, but the extension does not seem to currently implement that, so I'm unclear if there would be nefarious captive portals that would not issue redirects so that such a check would be necessary.
[GitHub comment by nhirata on 2012-07-30T17:15:10Z] Still seeing issues with this. Noming Otoro phone, build 2012-07-30 Taken from default.xml in b2g-distro: * "platform_build" revision= 2163d79af8c06ffcf7607a83e01dc5bf1107fd8e * "gaia" revision= 759caf5aa151ce06ce580e0a9ddb6ffe24ff8334 * "mozilla-central" revision= 07226cfa1211b2f8fc7702345a7184fae7c3962b * "gonk-misc" revision= c6a9a256cd4a1c53696488739d36778b9dbfc881
[GitHub comment by clarkbw on 2012-08-02T20:07:56Z] A common issue I've seen in other people trying to implement this feature is that they use an https url for their static page check. With an https url you'll need to monitor if you're getting a false certificate as well because many captive portals will deliver their certificate as the site cert you're expecting when checking something like https://mozilla.org/lib/static.txt for a redirect. This is a similar error I'm seeing now in Firefox where the new https google search gives a cert error because of the captive portal.
[GitHub comment by timdream on 2012-09-09T08:53:13Z] Why is this still blocking+? We are not implementing this for v1 right?
[GitHub comment by timdream on 2012-09-09T08:53:21Z] @autonome ^
[GitHub comment by nhirata on 2012-09-10T06:14:24Z] If you can't log into captive portal sites, you won't have wifi connections at various places like airports, coffee shops,... possibly LAN shops as well. Apparently, the use of LAN shops are pretty common in Brazil?
[GitHub comment by timdream on 2012-09-10T06:26:37Z] @nhirata people will encounter login screens when the load any of the browser tabs.
[GitHub comment by autonome on 2012-09-11T22:37:17Z] Yep, we discussed quite a while ago that this is a nice-to-have for V1. Blocking-.
Is this a dupe of bug 752982 ?
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 752982
BTW, bug 752982 is for the detection algorithm in handset. However, we doesn't really setup a web page for returning the detection result. The captive portal dialog will be shown until the server-side is ready. Currently there is no conclusion about whether Mozilla or partner should be responsible for setting up the server-side.
You need to log in before you can comment on or make changes to this bug.