Open Bug 1202680 Opened 9 years ago Updated 2 years ago

[userstory] Automatic Captive Portal detection

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect

Tracking

()

People

(Reporter: javaun, Unassigned)

References

(Depends on 10 open bugs)

Details

(Whiteboard: [fxprivacy][userstory])

User Story

SUMMARY:
As a user, I want Firefox to quickly bring up the login screen for my hotel's wifi, so I can connect and get online. 

AC: 
* Fx automatically detects the captive portal and opens the captive portal login page in a new tab in the active window.
* (Note: Firefox only displays the captive portal login page if the OS has not already done it.)
* User sees a notification bar stating (COPY NOT FINAL) "This network may require you to login to connect to the Internet. Firefox has opened the login page for you."
* Only one captive portal tab is open at a time. If an existing captive portal tab is open (either the current captive portal or a new one), reload that captive portal tab and make it the active tab.
* User can dismiss the notification by clicking the "X" on the far right side.

Attachments

(3 files, 2 obsolete files)

captiveportal.png
(deleted), image/png
Details
Captive Portal Logic Diagram - i02
(deleted), image/png
Details
"Fake" captive portal (node script - updated)
(deleted), application/x-javascript
Details
No description provided.
User Story: (updated)
Whiteboard: [fxprivacy][userstory]
Attached image captiveportal.png (deleted) —
Depends on: 1202684
User Story: (updated)
Attached image Captive Portal Logic Diagram - i01 (obsolete) (deleted) —
This is the logic diagram that accompanies the design spec. Note the big gap that happens after end. This gap separates two conditions: * Left: captive portal is detected. The end state is opening the login page. * Right: captive portal is detected, but user abandons the login page. The end state is the same: we open the login page. But there are certain messages shown and/or certain conditions. For v1 of implementation, we might want to focus solely on handling the logic on the left side. Let’s not worry about handling user abandonment of login page just yet.
Just to note, I think replacing the new tab page with the login screen might not be the best UX for this. First of all, it's surprising for the user. Second, the user might want to navigate to a page that doesn't require the captive portal, such as localhost, or some other page that doesn't require logging in, and this would just be getting in the way. I had a discussion with :ttaubert at some point and he seemed to agree.
Valentin's comment 4 makes a lot of sense to me, but I think it applies more to bug 989195 than Bram's latest diagram. Bram, what do you think? Should we WONTFIX that bug?
Flags: needinfo?(bram)
WONTFIXing that bug sounds like a good idea. However, on the New Tab/localhost/etc. pages, should we still show a status bar indicator that says “This network may require you to login to use the internet. [Click here to show login page]”?
Flags: needinfo?(bram)
(In reply to Bram Pitoyo [:bram] from comment #6) > WONTFIXing that bug sounds like a good idea. > > However, on the New Tab/localhost/etc. pages, should we still show a status > bar indicator that says “This network may require you to login to use the > internet. [Click here to show login page]”? I think we should still show it. For example, if I load localhost/index.html and that page loads a remote image or iframe, that load will run into the captive portal. It seems to me that the status bar always offers a useful reminder that we're in a captive portal, and a one step way to get to the login page.
Is there anything blocking work on the UI?
Only resource availability, but it's currently high in our team's priority list, so it should be getting some attention soon.
This bug's title has been tickling me for a while, so I'm rewording it. Please feel free to revert or improve my change.
Summary: [userstory] Captive Portal login page automatically → [userstory] Automatic Captive Portal detection
Attached file "Fake" captive portal (node script) (obsolete) (deleted) —
This is a node script that emulates a crude captive portal. Please see the comment in the script for details.
(In reply to Nihanth Subramanya [:nhnt11] from comment #13) > Created attachment 8805055 [details] > "Fake" captive portal (node script) > > This is a node script that emulates a crude captive portal. Please see the > comment in the script for details. To be clear, I'm attaching this because I've been using it to test stuff out locally and thought it might be useful to others as well. :)
Depends on: 1318640
Attached image Captive Portal Logic Diagram - i02 (deleted) —
Posting an updated logic diagram that addresses the latest behaviours on bug 989197.
Attachment #8658485 - Attachment is obsolete: true
Depends on: 1320113
Depends on: 1320327
Depends on: 1320100
Depends on: 1320330
Depends on: 1323514
Depends on: 1332630
I am working on a browser based application, which communicates to a local web server _without_ internet connection. Now, because of the new captive portal detection, in firefox the notification bar shows up, and, in case the user closes it, still every 3s I see FF trying to access http://detectportal.firefox.com/success.txt. Which will never succeed. Is there any definite method, to simulate the internet connection ? Looks like, simply responding by replying "success" to http://detectportal.firefox.com/success.txt is not sufficient (FF 52.0). (Does certificate error interfere here ?) In other words, in the diagram from above, how to force 'NO' to "IF network requires login" _and_ to force 'YES' "IF internet connection is active" ?
(In reply to augustus_meyer from comment #16) > I am working on a browser based application, which communicates to a local > web server _without_ internet connection. > Now, because of the new captive portal detection, in firefox the > notification bar shows up, and, in case the user closes it, still every 3s I > see FF trying to access http://detectportal.firefox.com/success.txt. Which > will never succeed. If you want to disable captive portal checking, you can set the network.captive-portal-service.enabled pref to false. > Is there any definite method, to simulate the internet connection ? Looks > like, simply responding by replying "success" to > http://detectportal.firefox.com/success.txt is not sufficient (FF 52.0). > (Does certificate error interfere here ?) The checking is over http, so no certificate is involved. I think returning "success" should work. Not sure why it doesn't for you. Another way of not triggering the CP detection would be for the connection to time out. So, maybe don't intercept requests to detectportal.firefox.com ?

Small update to the fake portal node script, the old one neglected to mention that the canonicalContent pref also needed to be set to "success" (the default value has a newline). This new version simply includes the newline in the canonical response, so no need to change the pref.

Attachment #8805055 - Attachment is obsolete: true
Depends on: 1622801
Depends on: 1747535
Depends on: 1740972
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: