Open Bug 720696 Opened 13 years ago Updated 2 years ago

New preference to delay DM auto-close when all downloads complete

Categories

(Toolkit :: Downloads API, defect)

x86_64
Windows 7
defect

Tracking

()

UNCONFIRMED

People

(Reporter: R.Kelley.Cook, Unassigned)

Details

Currently there are two options for the auto-close feature of the download manager it is controlled by a boolean pref browser.download.manager.closeWhenDone

If I'm not downloading anything I don't need this window open so I (like many others I suppose) enabled closeWhenDone by Clicking "Close it when all downloads are finished" in the Options UI.

However, this closes the windows instantly upon completion.  It should wait a few seconds

Example of usage: the system may be downloading large files (say a Linux ISO) in the background, so the user goes to browse other features.  All the while the download windows is showing of its progress, but if its large enough to take a few minutes, the user may not pay close attention.

But they don't need to pay attention since the notification popup will tell the user when that download is complete.  Unfortunately, as soon as that popup window appears, the DM window will have closed and the use will be forced to reopen it.  Not extremely hard if they know to hit Ctrl-J to reopen it, so I they can actually launch that file.  Somewhat harder to find if they don't know about the shortcut.  But they shouldn't have to do this.

Also I now that you can mouse over to the notification window and click on the link to bring the download window back up, but the window shouldn't have closed quite yet.

I propose that there is a new preference (say b.d.m.autoCloseDelay) giving a delay for close in milliseconds, with a default of 4000 milliseconds (double the length that the notification stays up) if b.d.m.closeWhenDone is true.

This pref would be ignored if b.d.m.closeWhenDone is false.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.