1019146 - Trying to connect to Mozilla-G (WPA-EAP) in the FTE fails to connect, even though it's displayed as an available wifi connection

Status: VERIFIED FIXED

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

Description

[Jason Smith [:jsmith]]

Build:

* Version: 2.0
* Gaia: 82679a5ce84d1b6bf388da6536d5682a3ad56de3
* Gecko: 6a984e21c2ca
* Build ID: 20140602072051
* Device: Flame

STR

1. In the FTE, try to connect to Mozilla-G with a valid username & password

Expected

Mozilla-G should be able to be connected to if it's displayed.

Actual

Mozilla-G fails to connect.

Comment 1

[Jason Smith [:jsmith]]

Attachment: Logcat

Comment 2

[Jason Smith [:jsmith]]

We either need to fix this or disable the UI here for this WPA-EAP style of network.

Comment 3

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Caused by FTU didn't adopt it's call to WifiHelper.setPassword(), it requires extra arguments, 'eap', in WPA-EAP mode.

If we do want to add a selection for eap and phase2 mode, I think we can set eap = PEAP, which seems to be most commonly used, in FTU, as my Gaia branch[1].

Another solution is adding selection, of course this will make FTU more complicated.

[1] https://github.com/chuck-lee/gaia/tree/bug-1019146

Comment 4

[Gerry Chang [:gchang]]

There is a typo error in the fix.
WifiHelper.setPassword(network, password, user. 'PEAP');
The dot (.) after user should be ','.
After trying the fix, Mozilla-G can be connected.

Question: 
Not sure if hard-coded 'PEAP' is a ultimate solution for this issue.

Comment 5

[Jason Smith [:jsmith]]

Sorry, I don't understand the question here.

Comment 6

[Gerry Chang [:gchang]]

There are 4 methods SIM, PEAP, TLS, and TTLS in EAP. 
And, we use 'PEAP' as default EAP method in FTU. If the wifi network uses other methods instead of 'PEAP', user still can't connect to wifi network in FTU.

Comment 7

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

(In reply to Gerry Chang [:cfchang] from comment #4)
> There is a typo error in the fix.
> WifiHelper.setPassword(network, password, user. 'PEAP');
> The dot (.) after user should be ','.
> After trying the fix, Mozilla-G can be connected.

Oops! fixed now   :P

> 
> Question: 
> Not sure if hard-coded 'PEAP' is a ultimate solution for this issue.

Ultimate solution is add method selection in FTU like in settings app, if it's acceptable for UX.

Comment 8

[Fernando Campo (:fcampo)]

(In reply to Chuck Lee [:chucklee] from comment #7)
> > Question: 
> > Not sure if hard-coded 'PEAP' is a ultimate solution for this issue.
> 
> Ultimate solution is add method selection in FTU like in settings app, if
> it's acceptable for UX.

IMO we should go for adding selection, even if it's more work. Code should be sync, and user should be able to have the same experience with both apps.
Said that, if this ends up being a blocker, I might consider the quick fix for speed.

Comment 9

[Tony Chung [:tchung]]

broken feature bug

Comment 10

[Gregor Wagner [:gwagner]]

(In reply to Chuck Lee [:chucklee] from comment #3)
> Caused by FTU didn't adopt it's call to WifiHelper.setPassword(), it
> requires extra arguments, 'eap', in WPA-EAP mode.
> 
> If we do want to add a selection for eap and phase2 mode, I think we can set
> eap = PEAP, which seems to be most commonly used, in FTU, as my Gaia
> branch[1].
> 
> Another solution is adding selection, of course this will make FTU more
> complicated.
> 
> [1] https://github.com/chuck-lee/gaia/tree/bug-1019146

Ken, can you help out here? Seems like your team has the most expertise here.

Comment 11

[Ken Chang[:kenkai]]

Because we have supported eap for wifi now, I think we should provide a menu/opinion for users. ni?UX
to know if they can design a new UX for this problem in FTU.

Comment 12

[Omega Feng [:Omega] [:馮於懋]]

Hi Rob, Could you help on FTU Wi-Fi UX?
Here is the Wi-Fi UX spec in bug 988150 for your reference.

Comment 13

[Rob MacDonald [:robmac]]

Hi Francis - With both Jacqueline and I away tomorrow could you or Val check into this one? - Rob

Comment 14

[Valentin Tsatskin [:vt]]

I'll take a look when I'm in later today

Comment 15

[Francis Djabri [:djabber]]

I agree that we should provide the users with the same options that they would be shown if they tried to connect to wi-fi. The FTE view should be the same as view on page 6 of the WiFi spec, but instead of OK and Cancel at the top of the view, there should be Back and Join buttons on the bottom of the view, as per the current FTE view. The Join button should only undimmed if the user enters some text in the Identity and Password fields. I will try to update the FTE spec tomorrow but thought I would comment now if this is time critical.

Comment 16

[Francis Djabri [:djabber]]

NI on Jacqueline to update the spec.

Comment 17

[Gregor Wagner [:gwagner]]

ping? It's getting pretty late for this now.

Comment 18

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to Fernando Campo (:fcampo) from comment #8)
> (In reply to Chuck Lee [:chucklee] from comment #7)
> > > Question: 
> > > Not sure if hard-coded 'PEAP' is a ultimate solution for this issue.
> > 
> > Ultimate solution is add method selection in FTU like in settings app, if
> > it's acceptable for UX.
> 
> IMO we should go for adding selection, even if it's more work. Code should
> be sync, and user should be able to have the same experience with both apps.
> Said that, if this ends up being a blocker, I might consider the quick fix
> for speed.

Since this is a blocker for 2.0, I suggest we take :chucklee's hardcoding PEAP patch for now and do the selection screen (which we still need the spec for) in a followup. We might still be able to squeeze it in for 2.0, but I suggest we at least get WPA-EAP wifi working in the meantime.

Comment 19

[Jacqueline Savory [:jsavory] UX]

Attachment: FTE Wifi_AP.pdf

I'm very sorry for the delay here, I agree with Francis and we should take the approach of following the current wifi settings model and just adapt the screen to suit the FTE flow.  

I've adapted the Wifi Settings spec page 6 for the purpose of this bug and attached the screen. For more details about wifi, see the spec Omega mentioned in bug 988150. 

Also as Francis mentioned, the join button should only be undimmed if the user enters some text in the Identity and Password fields. Please let me know if I've missed anything.

Comment 20

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 8452483 [details]
FTE Wifi_AP.pdf

I agree this is the right approach, and the spec looks good to me. However, we are in the last sprint for stabilization, and changing the spec this late (which afaict also introduces new strings) causes a lot of risk for regression in 2.0, and puts pressure on the developer. I still think the right approach is to accept chucklee's stopgap, and complete the new spec work in a follow up (not blocking 2.0).

Comment 21

[Jason Smith [:jsmith]]

I don't see why this is getting a renom. This is a broken experience with WPA-EAP support right now. We need a solution here no matter what, even if that implies turning the feature off.

Comment 22

[Gregor Wagner [:gwagner]]

Let's land chucklees patch in a separate bug on 2.0 and keep this around to fix the actual problem.

Comment 23

[Jason Smith [:jsmith]]

(In reply to Gregor Wagner [:gwagner] from comment #22)
> Let's land chucklees patch in a separate bug on 2.0 and keep this around to
> fix the actual problem.

I'd prefer to do the opposite here. This issue was originally tracking the fix needed for 2.0 to ship WPA-EAP.

Comment 24

[Gregor Wagner [:gwagner]]

(In reply to Jason Smith [:jsmith] from comment #23)
> (In reply to Gregor Wagner [:gwagner] from comment #22)
> > Let's land chucklees patch in a separate bug on 2.0 and keep this around to
> > fix the actual problem.
> 
> I'd prefer to do the opposite here. This issue was originally tracking the
> fix needed for 2.0 to ship WPA-EAP.

Fine with me. I don't have a strong opinion here. chucklee, can you finish your idea here? Lets move the new UX spec to a follow-up bug.

Comment 25

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: Pull Reqeuest (master)

Based on previous discussions, provide workaround for resolving WPA-EAP connection issue in FTE.

Comment 26

[Ken Chang[:kenkai]]

Chuck is working on it. However, it is a workaround.

Comment 27

[Fernando Campo (:fcampo)]

Comment on attachment 8453512 [details] [review]
Pull Reqeuest (master)

Left a comment on github for adding some details to the code for future fix.

I'd like some tests added, but realised that there's not a single test on connecting to networks. As this is a minor fix, and 2.0+, and have a followup (opened bug 1036829), I can live without them right now.

Comment 28

[Carsten Book [:Tomcat]]

seems travis reported a error like  ․․․JavaScript warning: app://communications.gaiamobile.org/common/vendor/chai/chai.js?time=1405048340230, line 1135: mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create - is this expected ?

Comment 29

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

The patch only add a parameter to a function call, which is not related to chai.js.
I think it shouldn't cause any warning but don't know why it do.

Comment 30

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to Carsten Book [:Tomcat] from comment #28)
> seems travis reported a error like  ․․․JavaScript warning:
> app://communications.gaiamobile.org/common/vendor/chai/chai.
> js?time=1405048340230, line 1135: mutating the [[Prototype]] of an object
> will cause your code to run very slowly; instead create the object with the
> correct initial [[Prototype]] value using Object.create - is this expected ?

This is a bug in chai that has been around for a while, and I don't think we expect them to fix it anytime soon.

master: https://github.com/mozilla-b2g/gaia/commit/ee1d3d529cd97fa8211cc8597e3e7bce47e0c2c6
2.0: https://github.com/mozilla-b2g/gaia/commit/726ca25ef1dbb83d8ed8a902b46fb340a3f95927

Comment 31

[Gerry Chang [:gchang]]

Verified @
Gaia      8cb1a949f2e9650bb2c5598e78a6f24a58bbaf97
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/c6f9f0396153
BuildID   20140720160208
Version   32.0a2