834122 - [Captive Portal] Make Captive Portal work with FTU

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::First Time Experience, defect)

Description

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

Currently the implementation of captive portal is using the notification to open browser app.
However this doesn't work if the user is using FTU and tries to connect to a captive portal.

1. Need to modify FTU.
2. Open browser app in FTU app is an unconfirmed behavior now. Maybe the user couldn't back to FTU again.

Proposal here is using window.open instead of browser activity.

Comment 1

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

adding product/UX for further comment. since it's not part of the user story but it's a good suggestion from alive.

Comment 2

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

Before going too further, I still need some UX feedback/confirm here.
Josh, could you give some support?

*Problem*
Our design of captive portal is 'Once system knows the wi-fi is captive portal, open browser app.'. Hence, when you are in one app, you would be switched to browser app.
But in FTU we shouldn't do this. Switch to browser app would break the flow of FTU. (don't know how to go back to FTU. We don't have hardware back button ;))

*Proposed change*
Use window.open -- entry sheet instead.
Create a system-wide entry sheet, put a mozbrowser iframe which url is captive portal's url.

*Question & Concern*
Q: The title bar's text should be...'Login'?
C: Not very trivial change but still implementable...I guess.

Comment 3

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

Want to make sure everyone knows that Shira is targeting 2/15 code freeze. 
Shira+ bugs needs more attention for unassigned, needinfo?,  review?
Full regression test is planned on 2/6. Need to have shira+ bugs landed by the end of 2/5 to be covered in full regression testing. Thanks

Comment 4

[Casey Yee]

(In reply to Alive Kuo [:alive] from comment #2)
> *Proposed change*
> Use window.open -- entry sheet instead.
> Create a system-wide entry sheet, put a mozbrowser iframe which url is
> captive portal's url.

This sounds like a good solution.   When the user closes the window they will be returned back to the FTE.

> 
> *Question & Concern*
> Q: The title bar's text should be...'Login'?

Would it not make sense to use whatever <title> is being defined within the captive login page?    Also, I'm not sure that we show anything except the URL here for security reasons.

NeedInfo: Paul and Lucas for comment about this.

Comment 5

[Casey Yee]

window.open IxD docs here for reference:
https://www.dropbox.com/s/mcqm1e3dxnoh7f0/Gaia_WindowOpen_20120917.pdf

Comment 6

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

(In reply to Casey Yee [:cyee] from comment #4)
> Would it not make sense to use whatever <title> is being defined within the
> captive login page?    Also, I'm not sure that we show anything except the
> URL here for security reasons.

URL/origin sounds a good idea.

> 
> NeedInfo: Paul and Lucas for comment about this.

Comment 7

[Lucas Adamski [:ladamski]]

I think we should show the URL there per the spec.

Comment 8

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

Attachment: https://github.com/mozilla-b2g/gaia/pull/7979

Patch v1:
1. Set default value of wifi.connect_via_settings to false, or else sth bad would happend when you |reset-gaia|.
2. Try to create a browser class.
3. Try to create an entrysheet class.
(No old code using mozbrowser iframe/entry sheet is changed.)
4. Have a system level entry sheet when ftu meets captive portal

Comment 9

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 710568 [details]
https://github.com/mozilla-b2g/gaia/pull/7979

Looks alright but I would like to get some clarification on your plan before landing:

-- What's the relationship between AppWindow and Browser class? Is AppWindow going to be replaced, or rely on Browser class in the future?
-- I personally think Browser class should have a better name called BrowserFrame.
-- new EntrySheet() should probably not call open() by itself. There are might be use cases in the future where people would like to init it but not open() it

Comment 10

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

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #9)
> Comment on attachment 710568 [details]
> https://github.com/mozilla-b2g/gaia/pull/7979
> 
> Looks alright but I would like to get some clarification on your plan before
> landing:
> 
> -- What's the relationship between AppWindow and Browser class? Is AppWindow
> going to be replaced, or rely on Browser class in the future?

AppWindow would utilize Browser class to generate a mozbrowser iframe.
And any other container(which is not an app but needs a mozbrowser iframe)

> -- I personally think Browser class should have a better name called
> BrowserFrame.

I am fine.

> -- new EntrySheet() should probably not call open() by itself. There are
> might be use cases in the future where people would like to init it but not
> open() it

Agree.

Comment 11

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

https://github.com/mozilla-b2g/gaia/commit/cff23a80c41b7de223d27c6a6f1f82f95c9c5f6b  v1-train
https://github.com/mozilla-b2g/gaia/commit/a7c3b3801954c35e8d72c0ae60724e97bd8cc718 master

Comment 12

[Lukas Blakk [:lsblakk] use ?needinfo]

Batch edit: bugs fixed on b2g18 since 1/25 branch of v1.0 are fixed on v1.0.1

Comment 13

[Askeing Yen[:askeing][:fyen]]

Unagi
Gaia:     819afb8758de9fbf87eca837e328818de93307ec
Gecko:    http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/96f559f949bb
BuildID   20130402230203
Version   18.0

Verified.