Download object should provide info which window it was initiated from

RESOLVED WONTFIX

Status

()

Toolkit
Downloads API
RESOLVED WONTFIX
5 years ago
9 months ago

People

(Reporter: Denis, Unassigned)

Tracking

26 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

We use onDownloadAdded()/onDownloadChanged() methods of object passed to DownloadList.addView() to detect when a download is started/stopped.  Our extension "iMacros for Firefox" should be able to replay different macros in different Firefox windows simultaneously. A few macros may initiate different downloads at the same time. So it is crucial for us to detect which window initiated a download. 


Actual results:

Currently there is no reliable way to do that.


Expected results:

We would like to have some Download object property which would somehow refer to the initiating browser window.
(Reporter)

Updated

5 years ago
Blocks: 907764

Comment 1

5 years ago
Thanks for the report!

Which technique do you use with the old API to detect which window initiated a download?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

5 years ago
In fact, we didn't handle it correctly. I realized it while adopting new Downloads.jsm API. 

We used window.opener as parameter in download dialog overlay to notify all the instances of iMacros player and every instance checked if its window is the opener. However, it does not solve timing issues. The fact that this window has just initiated a download doesn't really help to detect the moment when it is finished.

For example, one player (browser window A) may initiate downloading of very big file while another player (browser window B) initiates many downloads of very small files. In that case it is very likely that either player A won't wait for its download and continue replaying prematurely or player B will wait until download A is completed while it really shouldn't.

We discussed the issue and concluded that while it is not something a user faces everyday, there are real life applications where it becomes critical. I think that we have not had a flow of bug reports yet for only reason that very long downloading time is rare and possible delays are hardly noticeable. However, for some cases, such as automated web-site testing with enabled profiling, that issue becomes evident and leads to confusion.

Updated

2 years ago
Component: Untriaged → Download Manager
Product: Firefox → Toolkit

Comment 3

9 months ago
Closing the old compatibility bug now that legacy extensions are not supported anymore.
Status: NEW → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.