Confirm to cancel all downloads when process is umcompresing.

VERIFIED FIXED in Firefox OS v2.2

Status

Firefox OS
Gaia::System
VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: lolimartinezcr, Assigned: mikehenrty)

Tracking

unspecified
2.2 S10 (17apr)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(b2g-v2.2 verified, b2g-master verified)

Details

(Whiteboard: [systemsfe])

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
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 .
(Reporter)

Updated

4 years ago
Blocks: 1039501
Assignee: nobody → b.mcb
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?
Flags: needinfo?(b.pmm)

Comment 2

4 years ago
Created attachment 8502346 [details]
[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!
Flags: needinfo?(b.pmm)
Created attachment 8504009 [details]
Current behaviour

Comment 4

4 years ago
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!
Flags: needinfo?(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.
Flags: needinfo?(dhylands)
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.
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?
Flags: needinfo?(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.
Manuel, are you working on a patch? If not, I can do what Peter suggested in comment 7.
Flags: needinfo?(b.mcb)
Hi Michael, feel free to take the bug =)
Flags: needinfo?(b.mcb)
blocking-b2g: --- → 2.2?
Flags: needinfo?(gwagner)
QA Contact: mhenretty
Whiteboard: [systemsfe]
Assignee: b.mcb → mhenretty
QA Contact: mhenretty
Created attachment 8589375 [details] [review]
[gaia] mikehenrty:bug-1079244-fota-no-stop > mozilla-b2g:master
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 :)
Not blocking but very confusing UX.
blocking-b2g: 2.2? → ---
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?
Attachment #8589375 - Flags: review?(etienne)
Comment on attachment 8589375 [details] [review]
[gaia] mikehenrty:bug-1079244-fota-no-stop > mozilla-b2g:master

r=me with the comment addressed
Attachment #8589375 - Flags: review?(etienne) → review+
Keywords: checkin-needed

Updated

3 years ago
Keywords: checkin-needed

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
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
Attachment #8589375 - Flags: approval-gaia-v2.2?

Updated

3 years ago
Keywords: verifyme
(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
Flags: needinfo?(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.
(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.

Updated

3 years ago
Attachment #8589375 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
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.
Keywords: qawanted
v2.2: https://github.com/mozilla-b2g/gaia/commit/e539bb17f113934d4f8c1db0b3c188cc1638fe7d
status-b2g-v2.2: --- → fixed
status-b2g-master: --- → fixed
Target Milestone: --- → 2.2 S10 (17apr)
Status: RESOLVED → VERIFIED
status-b2g-v2.2: fixed → verified
status-b2g-master: fixed → verified
Flags: needinfo?(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
Keywords: qawanted, verifyme
Duplicate of this bug: 1136329

Updated

3 years ago
QA Whiteboard: [COM=OTA]
You need to log in before you can comment on or make changes to this bug.