Implement chrome.downloads.onDeterminingFilename

NEW
Assigned to

Status

()

Toolkit
WebExtensions: Request Handling
P3
normal
a year ago
18 days ago

People

(Reporter: aswan, Assigned: mstriemer)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [downloads]triaged)

(Reporter)

Description

a year ago
Part of supporting chrome.downloads in WebExtensions

https://developer.chrome.com/extensions/downloads#event-onDeterminingFilename
(Reporter)

Updated

a year ago
Blocks: 1213445

Updated

a year ago
Whiteboard: [downloads]

Comment 1

a year ago
See also bug 1123040 comment 18 and the rest of the discussion there.
See Also: → bug 1123040
(Reporter)

Updated

a year ago
Whiteboard: [downloads] → [downloads]triaged

Updated

9 months ago
Component: WebExtensions: Untriaged → WebExtensions: Request Handling

Updated

9 months ago
Priority: -- → P3
(Reporter)

Updated

4 months ago
Duplicate of this bug: 1340547

Comment 3

4 months ago
There's only 95 extensions in Chrome that use this API, so its very sparse, but I do think it will help with some of the concerns around existing Firefox extensions. It would allow extension developers to save files into a directory based on rules determined by the extension. Some of the extensions on bug 1246236 would benefit from this.
webextensions: --- → ?

Comment 4

4 months ago
Andy thank you for answer!
In fact, I do not know any other way to capture the downloading FTP file. Only onDeterminingFilename and it works well in chrome.
Our extension captures downloads and helps to download files.
Now there is a problem with FTP downloading.
If you could add this method to your API in the future it would be very usefull.

Updated

3 months ago
webextensions: ? → +

Updated

3 months ago
Assignee: nobody → mstriemer

Comment 5

a month ago
onDeterminingFilename is a must have feature to catch all browser's downloads in a right way (e.g. for a download manager).

Comment 6

27 days ago
After looking at a few factors: how complicated this is to implement in Firefox, how different our internals are from Chrome and the amount of usage it gets in Chrome Extensions (very little) I'm going to take this off the webextensions+ list for 57.

I doubt we'll be able to get this done in time and if we do it, we'd need to do it with some real underlying changes to Firefox.
webextensions: + → ---

(In reply to Andy McKay [:andym] from comment #6)
> After looking at a few factors: how complicated this is to implement in
> Firefox, how different our internals are from Chrome and the amount of usage
> it gets in Chrome Extensions (very little) I'm going to take this off the
> webextensions+ list for 57.

Hi Andy, I am working on a prototype (bug 1357160) that need some way to update target.path after download is created and since your team explored, it will be great if you can share issues found in getting this implemented. Thanks


> I doubt we'll be able to get this done in time and if we do it, we'd need to
> do it with some real underlying changes to Firefox.
Flags: needinfo?(amckay)
(Reporter)

Comment 8

18 days ago
(In reply to Punam Dahiya [:pdahiya] from comment #7)
> Hi Andy, I am working on a prototype (bug 1357160) that need some way to
> update target.path after download is created and since your team explored,
> it will be great if you can share issues found in getting this implemented.
> Thanks

In short, there are at least three different paths for starting downloads in Firefox, and not all of them are written in a way that facilitates asynchronously determining the target filename.  The three paths I know of are:
1. Downloads.createDownload()   http://searchfox.org/mozilla-central/rev/20963d7269b1b14d455f47bc0260d0653015bf84/toolkit/components/jsdownloads/src/Downloads.jsm#70
2. ContentAreaUtils.DownloadURL()  http://searchfox.org/mozilla-central/rev/20963d7269b1b14d455f47bc0260d0653015bf84/toolkit/content/contentAreaUtils.js#793
3. From uriloader/exthandler/nsExternalHelperAppService.cpp (difficult to point to a single line of code there...)

It is the third path that is most problematic for onDeterminingFilename.  The ideal solution would be significant refactoring of that code path to move a bunch of the logic into the Download objects in toolkit/components/jsdownloads/ but that is a pretty substantial undertaking.
Flags: needinfo?(amckay)
You need to log in before you can comment on or make changes to this bug.