907191 - [Downloads.jsm] "Remove from History" context menu option doesn't work anymore

Status: RESOLVED WORKSFORME

(Firefox :: Downloads Panel, defect)

Description

[Mihaela Velimiroviciu (:mihaelav)]

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

Comment 1

[:Paolo Amadini]

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.

Comment 2

[u279076]

Can the fix for this on Nightly be uplifted? If we can prevent shipping a regression we should.

Comment 3

[:Paolo Amadini]

(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.

Comment 4

[u279076]

(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).

Comment 5

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 6

[(mostly gone) XtC4UaLL [:xtc4uall]]

25 shipped -> can this get closed?

Comment 7

[Marco Bonardo [:mak]]

yes, it seems to work properly in Nightly and 25 was released.