Closed
Bug 804571
Opened 12 years ago
Closed 12 years ago
[OTA update] cancel download
Categories
(Firefox OS Graveyard :: Gaia::System, defect, P1)
Firefox OS Graveyard
Gaia::System
Tracking
(blocking-basecamp:+, firefox19 fixed, firefox20 fixed, b2g18 fixed)
People
(Reporter: etienne, Assigned: marshall)
References
Details
(Keywords: feature, Whiteboard: [ota update])
Attachments
(2 files)
(deleted),
patch
|
fabrice
:
review+
akeybl
:
approval-mozilla-aurora+
akeybl
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
(deleted),
text/x-github-pull-request
|
etienne
:
review+
|
Details |
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?
Reporter | ||
Updated•12 years ago
|
blocking-basecamp: --- → ?
Comment 1•12 years ago
|
||
Chris, how do you feel about this from a product standpoint?
Flags: needinfo?(clee)
Whiteboard: [blocked-on-input Chris Lee]
Updated•12 years ago
|
Whiteboard: [blocked-on-input Chris Lee] → [blocked-on-input Chris Lee], [ota update]
Comment 4•12 years ago
|
||
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•12 years ago
|
||
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)
Flags: needinfo?(clee)
Updated•12 years ago
|
Whiteboard: [blocked-on-input Chris Lee], [ota update] → [ota update]
Updated•12 years ago
|
blocking-basecamp: ? → +
Comment 6•12 years ago
|
||
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.
Reporter | ||
Comment 7•12 years ago
|
||
(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•12 years ago
|
||
(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.
Component: General → Gaia
Reporter | ||
Comment 9•12 years ago
|
||
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.
Assignee | ||
Comment 10•12 years ago
|
||
(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.
Assignee: nobody → marshall
Updated•12 years ago
|
Component: Gaia → Gaia::System
Comment 11•12 years ago
|
||
Hi Marshall, do you have an ETA for this fix?
Assignee | ||
Comment 12•12 years ago
|
||
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..
Assignee | ||
Comment 13•12 years ago
|
||
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
Attachment #686696 -
Flags: review?(fabrice)
Assignee | ||
Comment 14•12 years ago
|
||
Attachment #686712 -
Flags: review?(etienne)
Reporter | ||
Comment 15•12 years ago
|
||
Comment on attachment 686712 [details]
Gaia pull request 6724
Small comment on github, not a blocker.
Attachment #686712 -
Flags: review?(etienne) → review+
Updated•12 years ago
|
Attachment #686696 -
Flags: review?(fabrice) → review+
Assignee | ||
Comment 16•12 years ago
|
||
Updated•12 years ago
|
Comment 17•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
akeybl, does this need to get pushed down the channels in order to see the fix in the b2g nightly builds?
Flags: needinfo?(akeybl)
Comment 19•12 years ago
|
||
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.
Attachment #686696 -
Flags: approval-mozilla-beta+
Attachment #686696 -
Flags: approval-mozilla-aurora+
Flags: needinfo?(akeybl)
Updated•12 years ago
|
Keywords: checkin-needed
Comment 20•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/0664f7d24fab
https://hg.mozilla.org/releases/mozilla-b2g18/rev/62779170660b
status-b2g18:
--- → fixed
status-firefox19:
--- → fixed
status-firefox20:
--- → fixed
Keywords: checkin-needed
Updated•11 years ago
|
Attachment mime type: text/plain → text/x-github-pull-request
You need to log in
before you can comment on or make changes to this bug.
Description
•