Build: 2000-03-16-06-M15-nb1b(WIN), 2000-03-15-16-M15-nb1b(MAC), 2000-03-16-05-M15-nb1b (LINUX) 1. From http://jimbob/trigger2.html, click drop-down menu and choose a_addsubcomp_bigfile and click Trigger Case button 2. Click Cancel button from Download dialog to cancel download RESULT: Dialog dismisses and download appears to have ended. EXPECTED RESULT: Confirm dialog appears and inquires if user is certain that he/she wants to end the download and understands the consequences of the action. This is user-friendly and behaves as insurance in case this button was selected by accident.
reassign to dbragg.
Assignee: cathleen → dbragg
Target Milestone: M15
moving to M16
Target Milestone: M15 → M16
Nice feature.... It should be a simple Confirm() call. Maybe two or three lines.
Assignee: dbragg → cathleen
possibly for Beta3
Target Milestone: M16 → M18
Parcelling out Cathleen's bugs
Assignee: cathleen → dbragg
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so the queries don't get all screwed up.
Isn't this a duplicate of bug 42872 ? There's already a patch proposed there.
*** Bug 42872 has been marked as a duplicate of this bug. ***
Moving patch by Henrik Gemal over from 42872, adding keywords.
Keywords: patch, review
Created attachment 15192 [details] [diff] [review] [patch] by Henrik Gemal "Hooking up the cancel button in the download dialog"
Resetting target field for missed milestones
Target Milestone: M18 → ---
Whiteboard: [nsbeta3-] se-radar → [nsbeta3-] se-radar [xpiprd]
Moz 0.9 tasks
Priority: P3 → P5
Could you please add a config option in either the preferences or hidden in the configuation files themselves so people can elect to turn off this "feature"? Thanks...
Sorry, can't use this patch. Or, more accurately, this patch is for xpfe downloads not xpinstall "installation" downloads. Note the diff. It's compared to /mozilla/xpfe/components/xfer/resources/downloadProgress.js The progress dialog in xpinstall is xpinstall/res/content/xpistatus.xul and .js I personally feel that this would be an annoying feature. Note that in Windows Explorer if you're doing a large copy and hit cancel it simply cancels. It seems others agree with me (see above comment from Bruce Locke).
Why would you want to disable it? How often do people install software? What's the cost in frustration if they accidentally cancel a long download? This patch is not appropriate for this bug, nor is it a duplicate of 42872 which is an entirely different download dialog.
Summary: Confirm dialog should appear when cancelling a download → Need confirm dialog when cancelling an install download
Since the patch is for the wrong bug this is no longer low-hanging fruit. Hard to see how this enhancement moves us toward our customer happiness goal more than other problems we've got so taking off the nsbeta1 list.
Keywords: nsbeta1+ → nsbeta1-
Target Milestone: mozilla0.8.1 → Future
Whiteboard: [nsbeta3-] se-radar [xpiprd] → se-radar [xpiprd]
Don has moved to another group. Install bugs -> syd
Assignee: dbragg → syd
Status: ASSIGNED → NEW
*** Bug 164878 has been marked as a duplicate of this bug. ***
Close this, maybe?
You need to log in before you can comment on or make changes to this bug.