Open Bug 1255507 Opened 9 years ago Updated 1 years ago

Handle old downloads in downloads API

Categories

(WebExtensions :: Request Handling, defect, P3)

defect

Tracking

(Not tracked)

People

(Reporter: aswan, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [downloads]triaged)

Attachments

(1 file)

The current implementation of chrome.download.search() just fetches a list of downloads from Downloads.getList(), which only gets downloads from the current browser session (which also includes downloads that were in progress at the end of the previous session and were restored in the current session). For search() to retrieve historical downloads, we'll need to integrate with places and make an appropriate query.
Whiteboard: [downloads]
Downloads.jsm should return downloads from previous sessions, as long as they haven't been cleared. Is the downloads.search() API expected to remember downloads after they've been removed from the download manager?
> Downloads.jsm should return downloads from previous sessions, as long as they haven't been cleared. I don't think so. You switched from Downloads.jsm to the download manager, they're two different things. Although the Chrome documentation doesn't say this explicitly, I think the desired behavior is for results from search() to match what is visible in the download manager. But like I said above, download manager != Downloads.jsm. The download manager uses Downloads.jsm for details about downloads in the current session and places/history for details about downloads from past sessions (for example see https://dxr.mozilla.org/mozilla-central/rev/dd1abe874252e507b825a0a4e1063b0e13578288/browser/components/downloads/content/allDownloadsViewOverlay.js#470). chrome.downloads.search() currently just uses Downloads.jsm, this bug is about adding places support to bring search() in sync with what's visible in the downloads manager. Sorry if that wasn't clear from the description.
(In reply to Andrew Swan [:aswan] from comment #2) > > Downloads.jsm should return downloads from previous sessions, as long as they haven't been cleared. > I don't think so. > > You switched from Downloads.jsm to the download manager, they're two > different things. They are, but for this purpose they aren't. Removing a download from the downloads manager removes it from the views in Downloads.jsm. > The download manager uses Downloads.jsm for details about downloads in the > current session and places/history for details about downloads from past > sessions Hm. I see. Downloads.jsm only persists downloads that haven't finished at shutdown time. That didn't used to be the case.
Whiteboard: [downloads] → [downloads]triaged
Blocks: 1306879
Generalizing this to cover all of downloads, I don't think it will make sense to implement this piecemeal.
Summary: Handle old downloads in chrome.downloads.search() → Handle old downloads in chrome.downloads
Component: WebExtensions: Untriaged → WebExtensions: Request Handling
Priority: -- → P3
Downloads from blob:-URLs and data:-URLs do not appear in the about:downloads after restarting Firefox (bug? feature? IDK). So if you want to manually trigger a download for testing, do the following: 1. Visit example.com 2. Open the JS console for the tab. 3. Run the following code: a = document.createElement('a'); a.download='download'; a.href = '/?somedownload'; document.body.appendChild(a) a.click();
Depends on: 1381411
browser.downloads.search - does not display history from past sessions Acknowledgements: This API is based on Chromium's chrome.downloads API. https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/downloads/search But does not display the entire history of downloads for all time - returns the result only for the current browser session Expected results: Should be like as chrome.downloads.search from Chromium. In Google Chrome this function returns the entire download history for all time
Product: Toolkit → WebExtensions
Summary: Handle old downloads in chrome.downloads → Handle old downloads in downloads API
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:robwu, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(rob)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(rob)
Depends on: 1834338
Depends on: 1834437
Depends on: 1834440
Depends on: 1834447
Depends on: 1834451
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: