820287 - [Captive Portal] Need to be re-notified after the captive portal login expires

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Kai-Chih Hu [:khu]]

User story CP_004: 

""As a user, if my captive portal login expires, I want to be renotified of the need to log in."

UX: http://people.mozilla.com/~lco/Captive_Portal_B2G/

Comment 1

[Kai-Chih Hu [:khu]]

Should take this back to Taipei office.

Comment 2

[(inactive after 6/18) Alive Kuo [:alive]]

Arun, please provide the suggested wording in the notification. And how about using the regular notification to notify the user?

Comment 3

[Joe Cheng [:jcheng] (please needinfo)]

CC Casey/Josh to see if some feedback can be provided.

Comment 4

[Casey Yee]

On the desktop when your session expires you get directed to a login/session expired page if you are using the browser.  I don't see anything different here that we have to do on mobile?   

This of course doesn't work when you are not using the browser though.   Could we pop-up a browser browser window for these cases?

Comment 5

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Casey Yee [:cyee] from comment #4)
> On the desktop when your session expires you get directed to a login/session
> expired page if you are using the browser.  I don't see anything different
> here that we have to do on mobile?   
> 
> This of course doesn't work when you are not using the browser though.  
> Could we pop-up a browser browser window for these cases?

Open a new app "anytime" the network is gone sounds noisy. I don't know why user story needs this notification. I believe general case is no notification until you use the network..

Comment 6

[(inactive after 6/18) Alive Kuo [:alive]]

Don't think this is blocking. I don't see any device would tell you your wifi session is outdated. Do we really need this? From dev pov this is impossible because we don't know exactly when the session would timeout and polling the network with a timer is costing your money.

Comment 7

[Joe Cheng [:jcheng] (please needinfo)]

need more input from product. i agree with comment 6.
seem like this user story can be removed

Comment 8

[Kev Needham [:kev]]

The use case for this is similar to when you originally detect the captive portal initially. If you are connected to a wireless network and the captive portal detection is positive, then it should throw the dialog that you need to re-auth. The condition in comment 6 is actually met by a number of devices, because you're actively connected to the wireless network, and if the session expires any app using the network would stop working. I think this is necessary, but it should be something that's already covered using the same process as the initial connect and auth.

How is captive portal state tracked currently? Isn't the check constant?

I think the user story can be removed if the user will get the login dialog appears if they have an active wifi connection and the captive portal detection routine trips regardless of whether they've already authed in a session.

Comment 9

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

(In reply to Kev Needham [:kev] from comment #8)
> How is captive portal state tracked currently? Isn't the check constant?
In current implementation, we only check the captive portal state once when handset connects to a wifi ap.

Comment 10

[Joe Cheng [:jcheng] (please needinfo)]

triage: shira- and tracking. talked to Kev, this is not a hard blocker but would like to understand the effort/risk it takes to support the user story.

Comment 11

[Arun Balachandran Ganesan [:abc]]

Is this resolved? (seeing that Kev has mentioned that it should be covered by the existing process.)

Some small things (that may not matter)
Existing wording: "The network Neighborhood Cafe was found. Join network?"
Can we change it to this? "Wi-Fi network Neighborhood Cafe found. Join network?"

Should we mention "New Wi-fi network Neighborhood Cafe found. Join network?" when the user is connecting to it for the first time?

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

Don't think we could identify an access point is `new` or `old`.
Also this is not relevant to the original problem that we couldn't "immediately" knows and tells the user the login session times up.
But *if* somebody could guarantee that in this use case, the access point every time would provide a `fixed` period for Wi-Fi access, e.g., 30min, then we could do this.
Please file another bug about comment 11 if you insist.

(In reply to Arun Balachandran Ganesan [:abc] from comment #11)
> Is this resolved? (seeing that Kev has mentioned that it should be covered
> by the existing process.)
> 
> Some small things (that may not matter)
> Existing wording: "The network Neighborhood Cafe was found. Join network?"
> Can we change it to this? "Wi-Fi network Neighborhood Cafe found. Join
> network?"
> 
> Should we mention "New Wi-fi network Neighborhood Cafe found. Join network?"
> when the user is connecting to it for the first time?

Comment 13

[BMO Automation]

Firefox OS is not being worked on