Closed Bug 592902 Opened 10 years ago Closed 10 years ago
Provide a way to cleanup or stop accidental downloads
Bug 573982 changed our download flow. Downloads start without prompting the user and open in a helper app, if available. If not available, we save to a file. This might be nice when downloading on purpose, but if you accidentally start a download there is no way to stop it or delete it. Several possible ideas: * Add a cancel download notification bar. It only allows you to cancel the download. * Add a way to permanently delete a file from the download manager * Don't default to save-to-file. Only auto-download if we have a helper app to open the file. This would keep many accidental files from building up on the device. Saving to file could still be done using the contextmenu
Since tapping the notification now takes you to the download manager, I say we do all of this there. Maybe we just change the "remove" option from the download manager to a "delete" option? Or move all of these options to a context menu where we can be a bit more verbose (having both remove and delete seems like it would be confusing)?
Maybe clicking the row in the d/l manager should expandify it and let you choose from several options...
Actually deleting files through the dl manager is something we've wanted to allow in firefox for a long time. Makes sense especially on mobile where file managers are things people don't often have to / want to deal with. That said, that helps people only once they've already downloaded something (intentionally or not). To help people avoid the accidental download problem to begin with, I like the third suggestion in the original desscription. "* Don't default to save-to-file. Only auto-download if we have a helper app to open the file. This would keep many accidental files from building up on the device. Saving to file could still be done using the contextmenu"
Had more to say, but stopped being able to type in the browser. To continue: This means that you only automatically end up with a file if we know you have a reasonable UI (the other app) in which to deal with it -- we're not just abandoning the user.
That said, a "cancel" or other undo functionality in the notification could be useful - we just don't want to take too much of the tap target area of the notification. Does the android download notification through their status bar allow for cancelling?
From what I know, android's remoteviews allow us to put buttons or progress meters in the notifications (progress meter is Bug 592088). but for now we can't do much. We can't just leave users hanging when they click something, right? Just to be clear, if the user clicks on something that no helper app exists for we'll 1.) Cancel the download 2.) Show an alert/notification/toaster? telling them to... do something else if they really want the file?
(In reply to comment #6) > We can't just leave users hanging when they click something, right? Just to be > clear, if the user clicks on something that no helper app exists for we'll > 1.) Cancel the download > 2.) Show an alert/notification/toaster? telling them to... do something else if > they really want the file? I think the situation is #1 _or_ #2, not both. If no helper app exists, we cancel the download. If a helper app exists, we already show a notification. If the user clicks the notification, they are taken to the download manager, where they can cancel the download. We should have another bug (might already be filed) to delete files from the download manager.
Here's a patch. I really don't think we just want to cancel the download and not tell the user anything... do we? We need to explain to them what happened... don't we? Ideally we'd pass a better reason into the cancel method here (http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsNetError.h#71), and that reason would trickle down to the "dl-cancel" observer we have in downloads.js where we could show a special message. But it doesn't look like the reason makes it that far, and prying into moz-central just for this seems like a bit much.
Attachment #473123 - Flags: review?(mark.finkle)
Attachment #473123 - Flags: review?(mark.finkle) → review+
(In reply to comment #8) > Created attachment 473123 [details] [diff] [review] > Cancel downloads > > Here's a patch. I really don't think we just want to cancel the download and > not tell the user anything... do we? We need to explain to them what > happened... don't we? I am fine with that, as long as it fits our design based on use cases. Remember, this bug was originally about stop accidental downloads. Now, you are, thoughtfully, suggesting we tell the user we could download the file because there was no helper app. We have to make a best-case design from some guiding principals. Some of those principals include: * Don't nag the user with alerts * Try to be as unobtrusive as possible * Try to just do the Right Thing (expected thing) most of the time * Minimal UI and: * Opening a file in a helper app seems like a high priority use case * Downloading files, just plain old files, seems like low priority use case Based on these, I think the current patch works OK. Is it the best case for everybody? No, but we can't achieve that and still hit our design principals. Hopefully, we'll get some real world feedback and be able to adjust as needed. > Ideally we'd pass a better reason into the cancel method here > (http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsNetError.h#71), > and that reason would trickle down to the "dl-cancel" observer we have in > downloads.js where we could show a special message. But it doesn't look like > the reason makes it that far, and prying into moz-central just for this seems > like a bit much. Changing the message in the download alert is a great way to let the user know what happened and meets our design guidelines. We could even fire the alert from the HelperAppDialog code itself.
pushed: http://hg.mozilla.org/mobile-browser/rev/99c4b05339e8 Wes filed bug 594504 to tweak the popup alert to be more meaning for canceled downloads
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
verified FIXED on builds: Mozilla/5.0 (maemol Linux armv7l; rv:2.0b7pre) Gecko/20101029 Firefox/4.0b8pre Fennec/4.0b2 Mozilla/5.0 (android Linux armv7l; rv:2.0b7pre) Gecko/20101029 Firefox/4.0b8pre Fennec/4.0b2
Status: RESOLVED → VERIFIED
Flags: in-litmus?(ayanshah62) → in-litmus+
Assignee: nobody → wjohnston
You need to log in before you can comment on or make changes to this bug.