Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Support downloadItem.byExtensionId




WebExtensions: General
10 months ago
12 days ago


(Reporter: Mostafa Elsaie, Unassigned)


(Blocks: 1 bug)

51 Branch

Firefox Tracking Flags

(Not tracked)


(Whiteboard: triaged[downloads])


(1 attachment)



10 months ago
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393

Steps to reproduce:

1) Initiate a download from an extension using the
2) Try to analyse the dowloadItem in the downloads.onCreated event.
3) Look for the byExtensionId & byExtensionName attributes of the downloadItem.

Actual results:

Both attributes are always "undefined"

Expected results:

Both attributes should contain the extensions ID & Name respectively.


10 months ago
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64


10 months ago
Component: WebExtensions: Untriaged → WebExtensions: General
OS: Windows 10 → All
Hardware: x86_64 → All
Summary: downloadItem.byExtensionId always returns undefined → Support downloadItem.byExtensionId


10 months ago
Priority: -- → P3
Whiteboard: triaged


8 months ago
Whiteboard: triaged → triaged[downloads]

Comment 1

12 days ago
Created attachment 8884672 [details]

Confirmed in Firefox 55.0b5.

1. Install the attached add-on (via about:debugging for example).
2. Click on the extension button in the toolbar that appears after installing the extension.
3. Open the global browser console and look at the printed messages.

onCreated at 7/9/2017, 10:42:31 PM  background.js:2:5
id = 8  background.js:4:9
... (cut) ...
byExtensionId = undefined  background.js:4:9
byExtensionName = undefined  background.js:4:9 callback with ID: 8  background.js:12:9

Note hat byExtensionId and byExtensionName are both undefined, while they should have a sensible value.

The only place where the extension is set for a DownloadItem is for the callback of [1]. However, the downloads.onCreated event fires before that [2] and causes a DownloadItem to be created without extension. The result is cached too, so when the callback is invoked, the DownloadItem is not cached (nor updated with the extension).

Even if the above bug were to be fixed, the whole implementation would only work for downloads created in the current session; if the browser is restarted, the byExtensionId/byExtensionName fields would be cleared. Though if the browser is restarted, the downloads list would be empty anyway, because of bug 1255507.

And, if an extension is uninstalled, the byExtensionId and byExtensionName fields are cleared too (contrary to Chrome, which shows the ID and the last known name if the extension has been uninstalled).


Comment 2

12 days ago
(updating bug flags based on previous comment)
Ever confirmed: true
See Also: → bug 1255507

Comment 3

12 days ago
This is an interoperability issue too, so blocking bug 1213445.
Blocks: 1213445
You need to log in before you can comment on or make changes to this bug.