804571 - [OTA update] cancel download

Status: RESOLVED FIXED

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

Description

[Etienne Segonzac (:etienne)]

The latest spec for system and app updates (where both are merged) contains the ability to cancel all downloads.

No problem for the app updates, but is it doable for system updates?

Ideally gaia would send an mozContentEvent when the user asks for cancellation, then the UI goes back to the previous state (ie. indicating that X updates are available).

Thoughts? Blocker?

Comment 1

[Andrew Overholt [:overholt]]

Chris, how do you feel about this from a product standpoint?

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

This is especially obvious after the change to the spinning bob instead of the progress bar.

I get frustrated by the slow speed (not knowing how much progress has passed) and I tap to cancel, but it did not work. Maybe I'm missing something obvious here, and I hate to sound whiny, but why is there no longer a way to monitor the progress of downloading a system update (which tends to be larger than most apps)? With merely the spinning bob, it feels insufficiently fast on the office network, much less on slower wifis in target countries.

:(

I was about to file a bug when I searched, found this and 2 other bugs already filed as dupe.

The only workaround is to restart the phone in a frantic bid to get my download to cancel.

+1 to nomination for blocking-basecamp?.

===

My Git commit info currently shows:

2012-10-31 10:23:10
17fa1d86cea7377f89b5566826058a9406d44... (I see ellipsis at the end)

Comment 5

[Chris Lee [:clee]]

I believe we need this for the following reason:

*User clicks on 'download' and realizes that the size is much larger than their data prepaid plan allows and need to stop the transfer.
*Not a hard requirement for v1, but partial updates would be valuable for the initial region given state of their data connection availability. 
*Downloading something with out the option to cancel seems like basic UI (UX team can confirm if this is the case)

Comment 6

[Dave Hylands [:dhylands]]

Also, the user should be informed of the download size before initiating the download. You shouldn't have to wait until starting the download to determine the size.

Comment 7

[Etienne Segonzac (:etienne)]

(In reply to Dave Hylands [:dhylands] from comment #6)
> Also, the user should be informed of the download size before initiating the
> download. You shouldn't have to wait until starting the download to
> determine the size.

The download prompt now displays sizes! :)

Comment 8

[Josh Carpenter [:jcarpenter]]

(In reply to Chris Lee [:clee] from comment #5)
> I believe we need this for the following reason:
> 
> *User clicks on 'download' and realizes that the size is much larger than
> their data prepaid plan allows and need to stop the transfer.
> *Not a hard requirement for v1, but partial updates would be valuable for
> the initial region given state of their data connection availability. 
> *Downloading something with out the option to cancel seems like basic UI (UX
> team can confirm if this is the case)

Yep. In any mobile context canceling an activity that's consuming bandwidth is important. In our launch market, it's non-negotiable.

Comment 9

[Etienne Segonzac (:etienne)]

Not sure about the component choice, the majority of the work that needs to be done is on the platform side.

We already have a path to cancel downloads on the gaia side, but working only for apps right now.

Comment 10

[Marshall Culpepper [:marshall_law]]

(In reply to Etienne Segonzac (:etienne) from comment #9)
> Not sure about the component choice, the majority of the work that needs to
> be done is on the platform side.

Yeah, this is mostly a platform "bug" (feature). In a perfect world, we wouldn't give a "Cancel" button, but just a "Pause" button. Implementing pause / resume would probably a good deal harder, though.

I can tackle this.

Comment 11

[Dietrich Ayala (:dietrich)]

Hi Marshall, do you have an ETA for this fix?

Comment 12

[Marshall Culpepper [:marshall_law]]

I hope to have a patch and pull request up for this today, should be early next week for landing unless there are major problems with my approach..

Comment 13

[Marshall Culpepper [:marshall_law]]

Attachment: update download cancel - v1

This implementation actually pauses the download, and will automatically resume
the next time the user tries to download the update. In B2G, this translates to:

- User starts system update download from the notification
- User taps the in-progress download to cancel, and confirms cancelation in a prompt
- A new notification shows to download updates (including a system update)
- Starting the download from the new notification resumes the download from where
  it left off

Comment 14

[Marshall Culpepper [:marshall_law]]

Attachment: Gaia pull request 6724

Comment 15

[Etienne Segonzac (:etienne)]

Comment on attachment 686712 [details] [review]
Gaia pull request 6724

Small comment on github, not a blocker.

Comment 16

[Marshall Culpepper [:marshall_law]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/83c38674da8e

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/83c38674da8e

Comment 18

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

akeybl, does this need to get pushed down the channels in order to see the fix in the b2g nightly builds?

Comment 19

[Alex Keybl [:akeybl]]

Comment on attachment 686696 [details] [diff] [review]
update download cancel - v1

Yep, approving for branches preemptively since this is b-b+ and looks low risk.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/0664f7d24fab
https://hg.mozilla.org/releases/mozilla-b2g18/rev/62779170660b