Description: When the user is performing the FTU for the phone, they will encounter a Wi-Fi networks connection screen: the user can connect to any network found by their device and will be requested for a password when joining a secure network. If a user attempts to join a different network (NetB) after having already connected to a secured network (NetA), they may do so. Now, if the user attempts to connect to the previous secured network they had access to previously (NetA), they will be prompted for the password again. They will not be prompted however, if they complete the FTU and attempt to join in Settings, regardless if it's their active network when leaving FTU. PreReq: * fresh-flashed/reset device * secured network to join with a password * other network that may be joined Repro Steps: 1) Update a Flame to 20150204010225 2) Progress through FTU to Wi-Fi networks. 3) Attempt to connect to a secured network. 4) Input password for secured network to join. * ** Now connected to Network A * 5) Once connected, attempt to connect to a separate network. * ** Now connected to Network B * 6) Attempt to connect to Network A. 7) Observe password prompt. 8) Complete FTU while connected to Network B. 9) Goto Settings > Wi-Fi and connect to Network A. 10) Observe no password prompt. Actual: User will always be prompted for a password while joining networks in FTU, regardless if they have previously entered them successfully. When attempting to join these networks afterwards in Settings, no password prompt is observed revealing that it remembered the previous passwords. Expected: Once a user pushes a correct password to a Wi-Fi network, a password prompt will not be redistributed for the network until the network is forgotten. This reproes on flame 3.0, 2.2, 2.1 and 2.0 devices Environmental Variables: -------------------------------------------------- Device: Flame 3.0 Build ID: 20150204010225 Gaia: dfebaaa8aab43470f482d09d71137bab840c3ae9 Gecko: 0c2f7434c325 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0 Device: Flame 2.2 BuildID: 20150204002509 Gaia: a4c4cc86303a554facb8f45b7e764e5c4473c3de Gecko: 8669c26fd4a5 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 37.0a2 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Device: Flame 2.1 BuildID: 20150204002437 Gaia: 17bf14f12e43043654498330d610d469b8b55e64 Gecko: bdebcc47ec7a Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 34.0 (2.1) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Device: Flame 2.0 BuildID: 20150204000202 Gaia: 2989f2b2bd12fcc0e9c017d2db766e76a55873b8 Gecko: 69057b33ef5b Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 32.0 (2.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 -------------------------------------------------- Repro frequency: 5/5 See attached: video- http://youtu.be/ztK4u4jkn3E
QA Whiteboard: [QAnalyst-Triage?]
NI on Settings component owner for nomination decision and assignment.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(gchang)
For FTU its expected you have no stored passwords from previous use (obviously), and selecting a different network then switching back and needing to re-authenticate is a bug, but definitely an edge case. I wouldn't block on this personally, but I would like to see FTU and Settings aligned on behavior (and code ideally)
NI UX for more information about the behaviors.
Flags: needinfo?(gchang) → needinfo?(jsavory)
When the user connects to a WIFI connection in the FTU and then taps on that same connection again, they are prompted for a password. If the user puts in an incorrect password at this point, it will still be connected to that connection.
I agree with the expected result and Sam here, during FTU, correct passwords should be remembered be consistent with the settings behaviour.
@Gerry, this issue seems like what you said a few days ago?
Hi Vincent, Can you help to dispatch this to right owner?
Flags: needinfo?(gchang) → needinfo?(vchang)
Hi Sam, are you going to take this one, or we need to discuss with Arthur and sync the behavior between FTU and settings?
There is no doubt about the current behavior in settings app where we keep the password until the user intend to forget the network. Per comment 5 FTU should do the same thing but I agree with that this is an edge case.
(In reply to Vincent Chang[:vchang] from comment #8) > Hi Sam, are you going to take this one, or we need to discuss with Arthur > and sync the behavior between FTU and settings? Sounds like this is a bug that needs fixing in FTU. If I can fix it by sharing code from Settings I will.
Priority: -- → P3
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 4 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.