Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b2) Gecko/20100720 Firefox/4.0b2 When you install an add-on and want to pause and cancel the download, it will not work. Steps: 1. Open the add-ons manager 2. Search for an add-on which isn't installed yet 3. Install the add-on 4. Immediately try to hit the pause or cancel button on the download progress widget There is no reaction when clicking the above mentioned buttons.
Pause support would require bug 553024 which we aren't going to get done for 4.0 so we should just remove the pause button. Cancelling ought to work though.
Assignee: nobody → bmcbride
blocking2.0: ? → final+
We ought to remove the pause button, then. :)
Assignee: bmcbride → nobody
Removes the pause button, and hooks up the cancel button. Spent ages unsuccessfully trying to automate a test for this, before eventually giving up - so hows about we use a litmus test instead? :)
Attachment #501565 - Flags: review?(dtownsend)
Whiteboard: [good first bug] → [has patch][needs review Mossop]
(In reply to comment #3) > Removes the pause button, and hooks up the cancel button. Spent ages > unsuccessfully trying to automate a test for this, before eventually giving up > - so hows about we use a litmus test instead? :) Can you give more details where the problems are for a test?
Comment on attachment 501565 [details] [diff] [review] Patch v1 Looks good but yeah I'd really like to see an automated test here if we can. What were the problems you were seeing?
Attachment #501565 - Flags: review?(dtownsend) → review+
Whiteboard: [has patch][needs review Mossop] → [has patch]
Had trouble figuring out exactly when the cancel button could be clicked - essentially a timing issue, since httpd.js will serve the file so quickly. I could spend more time on it if you - but it would only be testing one simple line of code that's gluing things together (AFAIK, everything else is already tested).
To make httpd.js serving content slower, you will have to send the data on your own. I already gave that advice on another bug with the in-testsuite? flag set. It's up to you. If we don't have an automated mochitest, we can create a Mozmill test.
Let's get this landed when the tree re-opens and at the least add a litmus test for it. If we have time we can try to add a full automated test before release.
Whiteboard: [has patch] → [has patch][needs landing]
Whiteboard: [has patch][needs landing] → [has patch][needs landing][hard blocker]
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][needs landing][hard blocker] → [hard blocker]
Target Milestone: --- → mozilla2.0b10
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10pre) Gecko/20110112 Firefox/4.0b10pre ID:20110112033217 A Litmus and Mozmill test are possible.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.