Closed Bug 889623 Opened 9 years ago Closed 9 years ago

[FTE] need to be able to cancel Wifi Scanning

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::First Time Experience
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(b2g-v1.2 fixed, b2g-v1.3 fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
b2g-v1.2 --- fixed
b2g-v1.3 --- fixed

People

(Reporter: nhirata, Assigned: fcampo)

References

Details

(Keywords: uiwanted)

Attachments

(1 file)

PR https://github.com/mozilla-b2g/gaia/pull/13091
46 bytes, text/x-github-pull-request
julienw
: review+
gnarf
: feedback+
praghunath
: approval-gaia-v1.2+
Details | Review 
build: inari-mozilla-b2g18-20130702070214

1. flash inari-mozilla-b2g18-20130702070214
2. go through fte until wifi screen
3. on wifi screen try to cancel out of scanning networks

Expected: there should be a way to cancel out of it
Actual: no way to cancel or skip it; causing user to be stuck there since wifi scanning keeps continually happening.

Note: this ui request is for all devices.
Seems like a new feature.
blocking-b2g: koi? → -
This is a new feature, 1.3 or later. This seems like a feature request that should be made to Bruce Huang, System Platform team PM.
If a user ends up with a broken wifi scan, this can actually stop them from EVER being able to use the phone.  It doesn't "error" out, ever, it just sits on this screen (I tested it over the weekend, my phone was still waiting to find wifi).

I would encourage raising the priority of this bug significantly, because if someones wifi breaks and they factory reset to try to fix it and they encounter this bug...
blocking-b2g: - → koi?
+1
I personally think we should backport this fix as far back as we can get it (leo?)
UX-team, I don't understand why we have this modal dialog that prevents us from doing anything while scanning Wi-Fi. Maybe we could have another UX design that would get rid of this modal uncancelable dialog ? This would imo be better than adding a cancel button.

Having the UX as close as possible to the Settings app would work for me.
Flags: needinfo?(firefoxos-ux-bugzilla)
Hi Corey,

If we are back porting this fix to leo, why is it a koi? 

Also, can this be moved to 1.3?
Flags: needinfo?(gnarf37)
Adding Mike in Taipei to coordinate with Taipei UX on wifi.
Flags: needinfo?(mtsai)
Flags: needinfo?(firefoxos-ux-bugzilla)
Flags: needinfo?(bhuang)
I think that is a new feature for stop/skip wifi scanning when in FTU/FTE/OOB. 
Can Stephany put this feature to 1.3 or other versions ?
Flags: needinfo?(swilkes)
I really think the issue here is not to _stop/skip_ scanning but to _remove_ this modal overlay that makes no sense here.
I really think that we need to solve this bug as early as possible in our releases... 1.2, 1.1, etc are all now going to have a very serious bug if a wifi radio ever goes bad on a phone.  The tech support people are bound to suggest a factory reset, which will then have the user stuck waiting forever on a wifi scan screen in the FTU app.

This bug in my opinion is a very high priority "useless device results" bug.

Of course, I really can't make the decision of when we should fix it, but my suggestion is to fix it as early as we possibly can.  leo, koi, 1.3, all of the branches should have this fixed if possible.
Flags: needinfo?(gnarf37)
Let me coordinate here see if we can solve this issue asap before 1.3.
Flags: needinfo?(mtsai)
blocking-b2g: koi? → 1.3?
From what I know it's a new feature. As to the solution maybe set a timeout time or add a stop key may help .
I really want to know how "fix a problem that can result in a consumer having a bricked device" is a feature, or something you want to "wait for the next release" to fix.  Currently if I install a fresh 1.2 inari build on my device, I CAN NOT USE IT (without flashing a build of gaia that doesn't have the FTU enabled).  Of course, fixing wifi on the build is probably a priority, but this interface in the hands of a consumer with a broken wifi radio results in a completely useless device.

As to the solution, just remove the "modal" scanning dialog altogether, it doesn't seem to serve much of a purpose.  Timing out, or canceling are also good options.
I would say that a timeout can be a fix, and a button to stop it a feature (needs UX input). Maybe we can do it as a followup, but IMO this needs to be fixed.
Fernando, Mike, I still don't get why we can't just get rid of this wifi scanning screen ?
This problem bricks the phone. We need to fix this. Mike, can anyone on Systems Platform take on this temporary fix (like the timeout and button suggestion in comment #15 possibly, or the remove the modal scanning suggestion in comment #14)? If not, then I can ask Rob or Francis, though they are slammed on Sys FE, or barring our team a contractor. Ideally, UX could help with a fix and not spend more than about 30 minutes on this.

Then, we can try to get a longer term fix into Bruce's team backlog, as fixing wifi on the build is the source of this problem (not just the UI).

Let's update this soon with the UX person taking this.
Re-nominating for koi based on the last several comments -- it looks like we can come up with a low impact fix in for 1.2.
blocking-b2g: 1.3? → koi?
(In reply to Julien Wajsberg [:julienw] from comment #16)
> Fernando, Mike, I still don't get why we can't just get rid of this wifi
> scanning screen ?
Getting rid of it is easy, but it was a UX decision to include it, as we need to warn the user that something is going on. Whether is a full screen, or a spinner, or another different warning, personally I don't mind, but I don't want to go around changing the UX without agreement, because this kind of things brings future headaches.
Quick fix for the timeout.
Corey, could you check it? I'm unable to provoke an error on scan like the one you are having, I always get a normal request error.

Even if this is not the definitive/ideal solution, we could fix the bug, and look for optional/UX-compliant agreement on a followup.
Attachment #822245 - Flags: review?(felash)
Attachment #822245 - Flags: feedback?(gnarf37)
Comment on attachment 822245 [details] [review]
PR https://github.com/mozilla-b2g/gaia/pull/13091

some comments on github

please ask review again when you're ready :)
Attachment #822245 - Flags: review?(felash)
Comment on attachment 822245 [details] [review]
PR https://github.com/mozilla-b2g/gaia/pull/13091

comments addressed and tests added ;) hopefully working
Attachment #822245 - Flags: review?(felash)
I seem to be failed to sent this message yesterday, hope this is not too late :
I check the UI again and also knew that Fernando is in charge of the engineer side.
Here is my suggestion :
I agree with Julien's suggestion that simply just remove the scanning page.
We don't need the page, the scanning behavior can just follow what we have in Settings-> Scanning Devices.
This would be a neat and simple solution.
Thank you.
GoodMike> in 1.2 we're currently doing a simple timeout (simpler and safer fix), but we should definitely revisit this for 1.3.
Comment on attachment 822245 [details] [review]
PR https://github.com/mozilla-b2g/gaia/pull/13091

The code is ok, but I have comments for the tests you added (yay \o/), mostly nits

please ask r again once you're ready :)
Attachment #822245 - Flags: review?(felash)
Assignee: nobody → fer.campo.garcia+bugzilla
Comment on attachment 822245 [details] [review]
PR https://github.com/mozilla-b2g/gaia/pull/13091

Comments addressed. So far I kept the synchronous callback for the request, will probably deal with that on later pr.

Thanks for pointing out the attachTestHelpers function, didn't realize we had that (now I need to update a lot of tests :D)
Attachment #822245 - Flags: review?(felash)
Comment on attachment 822245 [details] [review]
PR https://github.com/mozilla-b2g/gaia/pull/13091

r=me

but I'd like that gnarf tests this with this broken phone before we land ;)
Attachment #822245 - Flags: review?(felash) → review+
Hey Corey,

would you please try this patch on your broken phone ? Thanks !
Flags: needinfo?(gnarf37)
(In reply to Julien Wajsberg [:julienw] from comment #27)
> Comment on attachment 822245 [details] [review]
> PR https://github.com/mozilla-b2g/gaia/pull/13091
> 
> r=me
> 
> but I'd like that gnarf tests this with this broken phone before we land ;)

Absolutely. Would be funny to merge a patch that doesn't work :D
Comment on attachment 822245 [details] [review]
PR https://github.com/mozilla-b2g/gaia/pull/13091

Correctly times out on the wifi broken device I have
Attachment #822245 - Flags: feedback?(gnarf37) → feedback+
Flags: needinfo?(gnarf37)
(In reply to Corey Frang [:gnarf] from comment #30)
> Comment on attachment 822245 [details] [review]
> PR https://github.com/mozilla-b2g/gaia/pull/13091
> 
> Correctly times out on the wifi broken device I have

So here we go!
merged on master 044080112cf1d4a97e46532bd5ff122334d5213a

Thanks to all

Should we open a followup for the other options we talked about (better UI, button to stop, etc) or keep this one open?
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Open a new bug. One bug == one patch :)
(In reply to Julien Wajsberg [:julienw] from comment #32)
> Open a new bug. One bug == one patch :)
we should make a t-shirt with that quote :D
Probably way too late to the party, but I agree that at least a time out is needed for koi.
Flags: needinfo?(bhuang)
Minus as the fix is already in master. Not needed for 1.2
blocking-b2g: koi? → -
Comment on attachment 822245 [details] [review]
PR https://github.com/mozilla-b2g/gaia/pull/13091

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): none
[User impact] if declined: if for some reason the wifi subsystem is broken, the user will want to reset the phone, loading FTU, and then the phone will be a brick.
[Testing completed]: yes
[Risk to taking this patch] (and alternatives if risky): none
[String changes made]: none

Please see comment 17, comment 34, comment 18. This fix was targeted at 1.2, with a very low-risk change. Please uplift this as it prevents a bricking behaviour.
Attachment #822245 - Flags: approval-gaia-v1.2?(praghunath)
please see previous comment 36
Flags: needinfo?(praghunath)
We're past the point of approvals. Why is this nominated for approval?
I don't know when this is the time for approvals. Why this is nominated: read comment 36. This is serious enough that we want it in 1.2.
Attachment #822245 - Flags: approval-gaia-v1.2?(praghunath)
Renominating. Please see comment 17, comment 34, comment 18, comment 36 for rationale.

Thanks.
blocking-b2g: - → koi?
Discussed in triage - we'll approve it, but not block on it.
blocking-b2g: koi? → ---
John, would you please uplift this patch to 1.2? Thanks!
Flags: needinfo?(swilkes)
Flags: needinfo?(praghunath)
Flags: needinfo?(jhford)
I was not able to uplift this bug to v1.2.  If this bug has dependencies which are not marked in this bug, please comment on this bug.  If this bug depends on patches that aren't approved for v1.2, we need to re-evaluate the approval.  Otherwise, if this is just a merge conflict, you might be able to resolve it with:

  git checkout v1.2
  git cherry-pick -x -m1 044080112cf1d4a97e46532bd5ff122334d5213a
  <RESOLVE MERGE CONFLICTS>
  git commit
Flags: needinfo?(fer.campo.garcia+bugzilla)
Flags: needinfo?(jhford)
conflict fixed and uplifted to v1.2 8e457f5fa5c9e63e884a97ab9699d0f9f3cb5fde
Flags: needinfo?(fer.campo.garcia+bugzilla)
(In reply to Fernando Campo (:fcampo) from comment #45)
> conflict fixed and uplifted to v1.2 8e457f5fa5c9e63e884a97ab9699d0f9f3cb5fde

Setting branch landing flag
status-b2g-v1.2: --- → fixed
Uplifted 044080112cf1d4a97e46532bd5ff122334d5213a to:
v1.3 already had this commit
status-b2g-v1.3: --- → fixed
Duplicate of this bug: 869029
You need to log in before you can comment on or make changes to this bug.