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)
Firefox OS Graveyard
Gaia::First Time Experience
ARM
Gonk (Firefox OS)
Tracking
(blocking-b2g:2.2+, b2g-v2.1 unaffected, b2g-v2.2 verified)
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
Reporter | ||
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: regression
Whiteboard: [2.2-Daily-Testing] [systemsfe]
Comment 1•10 years ago
|
||
Functional regression of a core feature. Requesting a window.
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: regressionwindow-wanted
Assignee | ||
Comment 2•10 years ago
|
||
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
Keywords: regressionwindow-wanted
Updated•10 years ago
|
blocking-b2g: 2.2? → 2.2+
Assignee | ||
Comment 3•10 years ago
|
||
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 4•10 years ago
|
||
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+
Comment 5•10 years ago
|
||
> 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)
Assignee | ||
Comment 6•10 years ago
|
||
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)
Comment 7•10 years ago
|
||
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)
Assignee | ||
Comment 8•10 years ago
|
||
Requesting check-in per comment 7. Let's wait for Jacqueline's comments, to open or not a follow-up
Keywords: checkin-needed
Comment 9•10 years ago
|
||
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)
Comment 10•10 years ago
|
||
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)
Comment 11•10 years ago
|
||
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)
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Updated•9 years ago
|
Flags: needinfo?(jsavory)
You need to log in
before you can comment on or make changes to this bug.
Description
•