1079244 - Confirm to cancel all downloads when process is umcompresing.

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Loli (:lolimartinezcr)]

Flame
2.2
User
Gecko-9764e19
Gaia-ded41a4

Pre-requisites:
Update available

STRs:
1. Drag and drop in utility try.
2. Tap in update available
3. Tap Download button.
4. Tap Download button.
5. One download has been done, tap in utility try in "umcompresing"

Actual result
"Are you sure you wanto to cancell all downloads?" is showed, but it hasn't sense because now is umcompressing

Expect result:
Need info UX about this behavior .

Comment 1

[Beatriz Rodríguez [:brg]]

Pau, could you please confirm that once the package had been downloaded, the user should not be asked about cancelling the download? Could you please confirm the expected behaviour?

Comment 2

[Pau Masiá [:Pau]]

Attachment: [2.1 Settings] OTA v1.0.pdf

Actually it doesn't have much sense. The normal process should be the one I attach in here, page 8. Thanks!

Comment 3

[Manuel Casas Barrado [:mancas]]

Attachment: Current behaviour

Comment 4

[Jenny Lee]

ni Dave for comment.

Hello Dave, 
Is it possible for user to stop the "uncompressing" process properly and start "uncompressing" later on (I assume the action can be done without internet connection, because supposedly, update has already been downloaded to device)? If the two stages "downloading" and "uncompressing" can be clearly separated, I will modify the string in the dialog when tapping on the notification that says "uncompressing" and expect stopping it to work correctly.
If there's risk to stop "uncompressing", I propose to not allow user tap on notification when it's in "uncompressing" stage. 
Let me know, thank you!

Comment 5

[Dave Hylands [:dhylands]]

Currently, I don't think that there is any way to stop the uncompressing process short of power cycling the phone or pulling the battery.

There is logic to detect that uncompressing was incomplete, and it will start uncompressing again when the user asks to apply the update again.

I think that it should be possible to add the functionality to stop uncompressing, but I'm pretty sure that functionality isn't currently present.

Comment 6

[Manuel Casas Barrado [:mancas]]

I'm not sure about if gecko can start and stop the uncompressing process or not. If gecko provides a way to do that then it is almost done, however, if we don't have a way to stop and restart the process, then we will need to make a patch for gecko, to implement that behaviour, and it doesn't sound good.

Comment 7

[Peter Dolanjski [:pdol]]

I suggest that, as Jenny indicated, we just prevent the user from interacting with the notification once it starts uncompressing.  
Gregor, do you know if this would need to be done in the System app and if so, what the level of effort would be?

Comment 8

[Gregor Wagner [:gwagner]]

(In reply to Peter Dolanjski [:pdol] from comment #7)
> I suggest that, as Jenny indicated, we just prevent the user from
> interacting with the notification once it starts uncompressing.  
> Gregor, do you know if this would need to be done in the System app and if
> so, what the level of effort would be?

Shouldn't be too hard. We might hit conditions where the unzipping is done before the user hits the cancel button and we show the dialog anyways but I guess we have to live with that.

Comment 9

[Michael Henretty [:mikehenrty][:mhenretty]]

Manuel, are you working on a patch? If not, I can do what Peter suggested in comment 7.

Comment 10

[Manuel Casas Barrado [:mancas]]

Hi Michael, feel free to take the bug =)

Comment 11

[GitHub Autolander Bot]

Attachment: [gaia] mikehenrty:bug-1079244-fota-no-stop > mozilla-b2g:master

Comment 12

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 8589375 [details] [review]
[gaia] mikehenrty:bug-1079244-fota-no-stop > mozilla-b2g:master

WIP without tests. I need a way to test this against FOTA. I'm asking around right now, but if anyone in this bug knows how please let me know here :)

Comment 13

[Gregor Wagner [:gwagner]]

Not blocking but very confusing UX.

Comment 14

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 8589375 [details] [review]
[gaia] mikehenrty:bug-1079244-fota-no-stop > mozilla-b2g:master

Yup, that did the trick for me. Added a test. Etienne, wanna have a look here?

Comment 15

[Etienne Segonzac (:etienne)]

Comment on attachment 8589375 [details] [review]
[gaia] mikehenrty:bug-1079244-fota-no-stop > mozilla-b2g:master

r=me with the comment addressed

Comment 16

[GitHub Autolander Bot]

Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/67d5014e2f9bd044cfbf590d258cdc27a901afa6

Comment 17

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 8589375 [details] [review]
[gaia] mikehenrty:bug-1079244-fota-no-stop > mozilla-b2g:master

I am requesting uplift approval of this UX issue. It is not blocking, but it is a partner requested feature and something which is not too risky to fix so I think we should just uplift it.


[Bug caused by] (feature/regressing bug #):
not a regression, always a UX problem

[User impact] if declined:
confusing UX, ie. user thinks they can cancel downloading an update when they cannot

[Testing completed]:
Manually tested, and added unit test.

[Risk to taking this patch] (and alternatives if risky):
this patch is about as simple a way to solve this issue as I can think of. risk is to cancelling an update download.

[String changes made]: none

Comment 18

[bhavana bajaj [:bajaj]]

(In reply to Michael Henretty [:mhenretty] from comment #17)
> Comment on attachment 8589375 [details] [review]
> [gaia] mikehenrty:bug-1079244-fota-no-stop > mozilla-b2g:master
> 
> I am requesting uplift approval of this UX issue. It is not blocking, but it
> is a partner requested feature and something which is not too risky to fix
> so I think we should just uplift it.
Given this is not a blocker, I am on the fence here. Getting QA verification to confirm the issue is fixed and make sure there are no fallouts. If there are no fallouts , given the above, will consider taking it.
> 
> 
> [Bug caused by] (feature/regressing bug #):
> not a regression, always a UX problem
> 
> [User impact] if declined:
> confusing UX, ie. user thinks they can cancel downloading an update when
> they cannot
> 
> [Testing completed]:
> Manually tested, and added unit test.
> 
> [Risk to taking this patch] (and alternatives if risky):
> this patch is about as simple a way to solve this issue as I can think of.
> risk is to cancelling an update download.
> 
> [String changes made]: none

Comment 19

[Peter Bylenga [:PBylenga]]

I tested with Friday's 3.0 nightly build, cancelling during uncompressing to today's build.  Tested: cancelling during different points of process, including a few restarts.

Only issue I saw was https://bugzilla.mozilla.org/show_bug.cgi?id=1136329 which pre-existed to this issue being fixed.

Leaving NI on me to try to cherry-pick this onto 2.2 and test it.

Comment 20

[bhavana bajaj [:bajaj]]

(In reply to Peter Bylenga [:PBylenga] from comment #19)
> I tested with Friday's 3.0 nightly build, cancelling during uncompressing to
> today's build.  Tested: cancelling during different points of process,
> including a few restarts.
> 
> Only issue I saw was https://bugzilla.mozilla.org/show_bug.cgi?id=1136329
> which pre-existed to this issue being fixed.
> 
> Leaving NI on me to try to cherry-pick this onto 2.2 and test it.

lets verify that in parallel post landing on 2.2, given you comment above on master this looks good to go.

Comment 21

[Peter Bylenga [:PBylenga]]

I cherry-picked this succesfully to Friday's v2.2 nightly build, I had to manually resolve a conflict.  Ran same set of tests, didn't see anything suspicious.  Will verify it again after it lands.

Comment 22

[Ryan VanderMeulen [:RyanVM]]

v2.2: https://github.com/mozilla-b2g/gaia/commit/e539bb17f113934d4f8c1db0b3c188cc1638fe7d

Comment 23

[Peter Bylenga [:PBylenga]]

Verified fixed for 2.2 and 3.0, you can't access the uncompressing notification successfully blocking the poor UX previously experienced.

Environmental Variables:
Device: Flame 3.0
Build ID: 20150415095209
Gaia: 2dd89fef4fae4d86fd313037ef384086c2e0e8a5
Gecko: 11077895df62
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Environmental Variables:
Device: Flame 2.2
Build ID: 20150415002502
Gaia: 0b2e2f7c022554d57bf2afed36ba6788249197dd
Gecko: 2356b82e9a50
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0