Closed Bug 919939 Opened 11 years ago Closed 7 years ago

Download object should provide info which window it was initiated from

Categories

(Toolkit :: Downloads API, defect)

26 Branch
x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: disya2, Unassigned)

References

Details

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.
Blocks: 907764
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
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.
Component: Untriaged → Download Manager
Product: Firefox → Toolkit
Closing the old compatibility bug now that legacy extensions are not supported anymore.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.