796338 - Captive portal pop up dialog is not automatically triggered on connect

Status: RESOLVED DUPLICATE of bug 752982

(Firefox OS Graveyard :: Gaia, defect)

Description

[GH to BZ]

[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

Comment 1

[GH to BZ]

[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?

Comment 2

[GH to BZ]

[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.

Comment 3

[GH to BZ]

[GitHub comment by clarkbw on 2012-05-14T22:11:43Z]
I looked into the iOS and Android approaches, not really sure what windows does.  I haven't updated that code in a while but you actually do want to do a checksum or string compare because some of the poorly implemented portals will give you a 200 and return their own page with a JavaScript redirect.  Yes, since logging my add-on behavior I've found that actually happens in the wild; SEATAC airport used to do this.  So you need to watch for a redirect for the better systems but when you receive a 200 you'll still need to check headers, checksum or the string compare the file to ensure you haven't been duped.

Comment 4

[GH to BZ]

[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

Comment 5

[GH to BZ]

[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.

Comment 6

[GH to BZ]

[GitHub comment by timdream on 2012-09-09T08:53:13Z]
Why is this still blocking+? We are not implementing this for v1 right?

Comment 7

[GH to BZ]

[GitHub comment by timdream on 2012-09-09T08:53:21Z]
@autonome ^

Comment 8

[GH to BZ]

[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?

Comment 9

[GH to BZ]

[GitHub comment by timdream on 2012-09-10T06:26:37Z]
@nhirata people will encounter login screens when the load any of the browser tabs.

Comment 10

[GH to BZ]

[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-.

Comment 11

[Julien Wajsberg [:julienw]]

Is this a dupe of bug 752982 ?

Comment 13

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

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.