[FTE][WiFi] Rebooting device after connecting to WiFi network does not reconnect to network

RESOLVED WONTFIX

Status

Firefox OS
Gaia::First Time Experience
RESOLVED WONTFIX
4 years ago
3 months ago

People

(Reporter: Jordan de Geus(JordanD), Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected)

Details

(Whiteboard: [2.1-exploratory-2], URL)

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Created attachment 8493357 [details]
logcat_20140922_1346.txt

Description:
When users enter FTE, upon entering and connecting to a WiFi network successfully, upon rebooting the device, users will not reconnect to their WiFi network. If users enable Data prior to rebooting the device, users will observe data is reconnected upon reboot.
   
Repro Steps:
1) Update a Flame device to BuildID: 20140922063004
2) During FTE progress to WiFi setup> Connect to a WiFi network
3) Press and hold power button> Restart
4) Observe users will not be connected to WiFi and user will need to reconnect to WiFi network

Actual:
Rebooting device during FTE after connecting to a Wireless network will not reconnect upon powering back on
  
Expected: 
Rebooting device after connecting to a WiFi network during FTE reconnects the device to the wireless network
  
Environmental Variables:
Device: Flame 2.1
BuildID: 20140922063004
Gaia: 689c4ad4d8c3e4aa95805a2e49ae6cf786a1ae91
Gecko: 185fc54d29c1
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Repro frequency: 3/3
See attached: Video and logcat

http://youtu.be/S-XD5vckYLY
(Reporter)

Comment 1

4 years ago
This issue DOES occur on Flame 2.2, Flame 2.1 KK, Flame 2.1 JB(512mb), Flame 2.0 KK, Flame 2.0 JB, Flame 1.4, Open C 2.2, Open C 2.1, Open C 2.0, Open C 1.4

Actual: WiFi networks are not reconnected upon rebooting device while in FTE after the users have previously connected to WiFi network
	
Flame 2.2 (319mb)

Environmental Variables:
Device: Flame 2.2
Build ID: 20140922040204
Gaia: c7ef0bf06ce1c98cbe68aa52e2ecd862acb23e9c
Gecko: 53f7f5b6d7bf
Version: 35.0a1
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Open C 2.2

Environmental Variables:
Device: Open_C 2.2
Build ID: 20140922040204
Gaia: c7ef0bf06ce1c98cbe68aa52e2ecd862acb23e9c
Gecko: 53f7f5b6d7bf
Version: 35.0a1
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Flame 2.1 KitKat (319mb)

Environmental Variables:
Device: Flame 2.1
Build ID: 20140922063004
Gaia: 689c4ad4d8c3e4aa95805a2e49ae6cf786a1ae91
Gecko: 185fc54d29c1
Version: 34.0a2
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.1 JB (512mb)

Environmental Variables:
Device: Flame 2.1
Build ID: 20140922000332
Gaia: b3f9b97d16a1ab55f80239d63c1a85c3da3d39ad
Gecko: 2c6e3261c47b
Version: 34.0a2
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.1 KK (512mb)

Environmental Variables:
Device: Flame 2.1
BuildID: 20140922063004
Gaia: 689c4ad4d8c3e4aa95805a2e49ae6cf786a1ae91
Gecko: 185fc54d29c1
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.0 KitKat Base (319mb)

Environmental Variables:
Device: Flame 2.0
Build ID: 20140922082143
Gaia: 0658006be8a00fdb5931ee15a0aa353a3ab231ba
Gecko: dc61f92b855e
Version: 32.0 (2.0)
Firmware Version:
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 2.0 (319mb)

Environmental Variables:
Device: Flame 2.0
Build ID: 20140922000331
Gaia: 0658006be8a00fdb5931ee15a0aa353a3ab231ba
Gecko: c0086da55273
Version: 32.0 (2.0)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Open_C 2.0

Environmental Variables:
Device: Open_C 2.0
Build ID: 20140922000331
Gaia: 0658006be8a00fdb5931ee15a0aa353a3ab231ba
Gecko: c0086da55273
Version: 32.0 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 1.4 (319mb)

Environmental Variables:
Device: Flame 1.4
Build ID: 20140922000333
Gaia: efa2b8cb095407df942fee7732a5547c7034ef9b
Gecko: 02154a103d43
Version: 30.0 (1.4)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Open C 1.4

Environmental Variables:
Device: Open_C 1.4
Build ID: 20140922000333
Gaia: efa2b8cb095407df942fee7732a5547c7034ef9b
Gecko: 02154a103d43
Version: 30.0 (1.4)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
Whiteboard: [2.1-exploratory] → [2.1-exploratory-2]
Not sure that this is a bug. It seems like it would be intended behaviour to completely restart the FTE when restarting the phone, while in the FTE.

Can you weigh in on this Marcia?
Flags: needinfo?(mozillamarcia.knous)
My opinion is that it does make sense that it would restart clean if you start all over again - I don't know what the is the expected behavior but I can try to find out. This will require going back to find the original specs that defined the behavior or asking someone in UX.
Flags: needinfo?(mozillamarcia.knous)
I agree, it would be good to know what is expected here
We've seen a few of these bugs now where unexpected behavior results from a shutdown/restart in the middle of a flow. I'm on the fence on this one. There's no way to un-select or disconnect from a network in the FTE right now, short of selecting another one. Restart is your escape hatch in this scenario. OTOH if you did lose power or need to shutdown mid-FTE, its not unreasonable to assume that steps already completed would preserve the values you selected when you start back up. 

What are you thoughts Jacqueline, can we bring down the spec hammer on this one? :)
Flags: needinfo?(jsavory)
I think that if the user restarts their device, either all information should be preserved or none of it. It would probably be best if it was consistent throughout the whole FTE. 

I am leaning towards maintaining all of the users changes, including the wifi networks. I think the best solution would be to add the same 'Forget' action that is present in the settings wifi to the FTE screen. That way we can have both the ability to forget a network and still maintain information on a restart. Let me know if this is possible. :) Spec hammer'd!
Flags: needinfo?(jsavory)
Not blocking on this, the user can still reconnect to wifi when going through the FTE after the restart
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris)

Comment 8

3 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.