Closed Bug 1102550 Opened 10 years ago Closed 10 years ago

[FTU] Enabling Airplane Mode via Power Menu and refreshing Wi-Fi Connections can block User

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.2+, b2g-v2.1 unaffected, b2g-v2.2 verified)

VERIFIED FIXED
2.2 S1 (5dec)
blocking-b2g 2.2+
Tracking Status
b2g-v2.1 --- unaffected
b2g-v2.2 --- verified

People

(Reporter: onelson, Assigned: mancas)

References

()

Details

(Keywords: regression, Whiteboard: [2.2-Daily-Testing] [systemsfe])

Attachments

(1 file)

Description:
While the user is performing the FTU, they are able to enable 'Airplane Mode' via the 'Power Menu' which can cause further disruption in the FTU that is not handled. With Airplane Mode enabled, if the user attempts to refresh their Wi-Fi Connection they will become blocked: The throbber will spin as if searching for networks, the Navigation UI buttons are disabled and the Home Button is unusable in FTU.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141120040205
2) Hold Power Button down to display 'Power Menu'.
3) Enable Airplane Mode.
4) Reach the 'Wi-Fi Connections' page in the FTU.
5) Refresh the connections.
6) Observe FTU UI.
  
Actual:
User is blocked: Throbber spins indefinitely and user cannot navigate away from network refresh screen.
  
Expected: 
User is informed that their Wi-Fi is disabled after enabling Airplane Mode.
-- OR --
User cannot enable Airplane Mode from the FTU.

*******************************
Environmental Variables:
----------------------------------------------
Device: Flame 2.2 Master
BuildID: 20141120040205
Gaia: 1abe09b4925547699dfdb2d358aed019137c3aa6
Gecko: 6ce1b906c690
Gonk: 
Version: 36.0a1 (2.2 Master)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
----------------------------------------------
===========================
Issue DOES NOT REPRO on flame 2.1 devices  
Results: After Enabling Airplane Mode and attempting resfresh and network connections, throbber stops and informs user that 'No wireless networks found.'

----------------------------------------------
Device: Flame 2.1
BuildID: 20141120001207
Gaia: f8d3bf44029e0afc0124600a4bb34dba8fc1ad21
Gecko: f70a67a7f846
Gonk: 
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
----------------------------------------------
*******************************
  
Repro frequency: 4/4
See attached:
video- http://youtu.be/JWrvW7vgGTA
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: regression
Whiteboard: [2.2-Daily-Testing] [systemsfe]
Functional regression of a core feature.

Requesting a window.
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Broken by bug 1067677

https://github.com/mozilla-b2g/gaia/commit/efd1a63719fc253f31f52ccbacefbe95ab880403#diff-4fc38b285d8320b93cd6f29033b7065aL61

removing regression-window-wanted tag, to avoid wasting resources and time because the patch is trivial and the root cause has been detected.

I'm working on it
Assignee: nobody → b.mcb
blocking-b2g: 2.2? → 2.2+
Attached file Proposed patch
Hey Fernando this issue was caused by the refactor in the wifi interface. I've solved the issue and the unit tests because they weren't working as expected.

Thanks!
Attachment #8528180 - Flags: review?(fernando.campo)
Comment on attachment 8528180 [details] [review]
Proposed patch

that refactor surely triggered a lot of regressions :(
thanks for fixing them.

After testing this, just an open question to UX and Sam (owner): do we prefer this new behaviour - empty response when error instead of keeping the old list, or would it be better to keep the existing list (if any)? Have in mind that there's no error message shown to the user, just an empty or full list of wifi networks.

I like this new one more, better to show nothing than a list that might not be real, but maybe you have a different opinion, or want to add an error message?
Flags: needinfo?(sfoster)
Flags: needinfo?(jsavory)
Attachment #8528180 - Flags: review?(fernando.campo) → review+
> After testing this, just an open question to UX and Sam (owner): do we
> prefer this new behaviour - empty response when error instead of keeping the
> old list, or would it be better to keep the existing list (if any)? Have in
> mind that there's no error message shown to the user, just an empty or full
> list of wifi networks.
> 
> I like this new one more, better to show nothing than a list that might not
> be real, but maybe you have a different opinion, or want to add an error
> message?

I agree that showing the old connections would be bad. It seems to me we should have an empty state message, otherwise its not clear if something's gone wrong or we are still waiting for results (networks). I see an error sporadically when getting the network list. Maybe there's a way to show that to the user - by way of explanation for why no networks were found? Tapping the refresh button seems to work every time for me, but it would be great to fix the underlying cause if possible.
Flags: needinfo?(sfoster)
What we can do is set an error message instead of the |No wireless networks found| message that the user see if there is no networks. However, the cause of the error not seems to be easy to recover because the api returns |Unable to scan for networks| if there is an error while searching networks.

What do you think?
Flags: needinfo?(sfoster)
Flags: needinfo?(fernando.campo)
I don't dislike the idea of using a Toaster.show() for the error, but I think this is more a UX decision, so still waiting for Jacqueline's input.

Anyways, I think we can merge this and work on the error message, if any, in a follow-up, as it looks more like a polish bug.
Flags: needinfo?(fernando.campo)
Requesting check-in per comment 7. Let's wait for Jacqueline's comments, to open or not a follow-up
Keywords: checkin-needed
Master: https://github.com/mozilla-b2g/gaia/commit/88ddc37b7c17b2f05aaf94a0c1abdbd3f7b16d05
Status: NEW → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S1 (5dec)
Ditto to comment 7, if we cant get at the underlying cause, in the meantime we should present the user with some information and next steps rather than hoping they'll hammer on the refresh button.
Flags: needinfo?(sfoster)
This issue is verified fixed on Flame 2.2.

Result: The error message appears soon every time the user taps the refresh button, and the page does not get stuck on the loading screen.

Device: Flame 2.2 (319mb, KK, Full Flash)
Build ID: 20141205040202
Gaia: 529c5fcd234ffd108b57629673ca97c2ef73376d
Gecko: e7f3e6fee15e
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 37.0a1 (2.2)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: needinfo?(jsavory)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: