Closed Bug 1019146 Opened 10 years ago Closed 10 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v1.4 unaffected, b2g-v2.0 fixed, b2g-v2.1 fixed)

VERIFIED FIXED
blocking-b2g 2.0+
Tracking Status
b2g-v1.4 --- unaffected
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: jsmith, Assigned: chucklee)

References

Details

Attachments

(3 files)

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.
Attached file Logcat
We either need to fix this or disable the UI here for this WPA-EAP style of network.
blocking-b2g: --- → 2.0?
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
Component: Wifi → Gaia::First Time Experience
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.
Flags: needinfo?(jsmith)
Sorry, I don't understand the question here.
Flags: needinfo?(jsmith)
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.
(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.
(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.
broken feature bug
blocking-b2g: 2.0? → 2.0+
Depends on: 1003054
Whiteboard: [systemsfe]
Target Milestone: --- → 2.0 S4 (20june)
No longer depends on: 1003054
(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.
Flags: needinfo?(kchang)
Whiteboard: [systemsfe]
Target Milestone: 2.0 S4 (20june) → ---
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.
Flags: needinfo?(kchang) → needinfo?(ofeng)
Hi Rob, Could you help on FTU Wi-Fi UX?
Here is the Wi-Fi UX spec in bug 988150 for your reference.
Flags: needinfo?(ofeng) → needinfo?(rmacdonald)
Hi Francis - With both Jacqueline and I away tomorrow could you or Val check into this one? - Rob
Flags: needinfo?(vtsatskin)
Flags: needinfo?(rmacdonald)
Flags: needinfo?(fdjabri)
I'll take a look when I'm in later today
Flags: needinfo?(vtsatskin)
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.
NI on Jacqueline to update the spec.
Flags: needinfo?(fdjabri) → needinfo?(jsavory)
ping? It's getting pretty late for this now.
(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.
Attached file 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.
Flags: needinfo?(jsavory)
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).
blocking-b2g: 2.0+ → 2.0?
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.
Let's land chucklees patch in a separate bug on 2.0 and keep this around to fix the actual problem.
Flags: needinfo?(kchang)
Flags: needinfo?(chulee)
(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.
(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.
Assignee: nobody → chulee
blocking-b2g: 2.0? → 2.0+
Attached file Pull Reqeuest (master)
Based on previous discussions, provide workaround for resolving WPA-EAP connection issue in FTE.
Attachment #8453512 - Flags: review?(fernando.campo)
Flags: needinfo?(chulee)
Flags: needinfo?(kchang)
Chuck is working on it. However, it is a workaround.
See Also: → 1036829
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.
Attachment #8453512 - Flags: review?(fernando.campo) → review+
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 ?
Keywords: checkin-needed
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.
(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
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Verified @
Gaia      8cb1a949f2e9650bb2c5598e78a6f24a58bbaf97
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/c6f9f0396153
BuildID   20140720160208
Version   32.0a2
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: