Build identifier: Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0, build id: 20130820004003 Steps to reproduce: 1. Start Firefox 25 (Aurora) with a new profile 2. Go to about:config and set the browser.download.useJSTransfer preference to true and restart the browser 3. Navigate to a page and perform a download 4. After the download is finished, right click on it in the download panel and select "Remove from History" Expected result: The download is removed from the downloads list both in the downloads panel and in the Library Actual result: Nothing happens - the download is not removed Notes: 1. The issue is not reproducible on the latest Nightly build: the result of performing the above steps is the expected result: Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0, build id: 20130820030206 2. The issue is not reproducible with the old nsIDownloadManager interface (i.e. not running the step 2 from above). 3. The issue is reproducible ever since the Downloads.jsm was introduced to Firefox 25.0a2 (August the 8th Aurora): Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0, build ID 20130808004004
status-firefox25: --- → affected
status-firefox26: --- → unaffected
Thanks a lot for testing this! As you noted, this was fixed in Nightly by bug 906314. There are several other bugs that were not ported to Aurora, the feature there is only ready for early testing by add-on developers.
Can the fix for this on Nightly be uplifted? If we can prevent shipping a regression we should.
tracking-firefox25: --- → ?
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #2) > Can the fix for this on Nightly be uplifted? If we can prevent shipping a > regression we should. This feature is actually disabled by default on Aurora, and to avoid patch conflicts we would need to uplift most of the work done in the meantime. We can do that, but I'm not sure it's worth the effort, unless we receive a request related to testing a specific add-on on Aurora.
(In reply to Paolo Amadini [:paolo] from comment #3) > This feature is actually disabled by default on Aurora, and to avoid patch > conflicts we would need to uplift most of the work done in the meantime. Thanks Paolo. Just as a point of process I would consider this bug a blocker to enabling Downloads.jsm on Aurora 25 (if that's ever open for consideration).
There's no indication (no tracking issues) for FF25 suggesting this will be enabled there, we'd likely not take on so much risk at this point so there's not regression being shipped to users (for whom this is off by default) and our early-adopter testers (add-on devs) should be able to understand what's happening here.
tracking-firefox25: ? → -
25 shipped -> can this get closed?
yes, it seems to work properly in Nightly and 25 was released.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.