198093 - pref to autoclose (toggle) download manager window

Status: VERIFIED FIXED

(Camino Graveyard :: Downloading, enhancement)

Description

[sairuh (rarely reading bugmail)]

couldn't find a bug on this, but dup as needed.

is there some way that we could automatically close the Downloads window, after
a download has completed?

Comment 1

[Neil Lee [:neilio]]

Yes, please. This, plus the fact that there's no preference right now to get the
download window to "clean up after itself" once a download is completed, makes
downloading w/ Camino rather unwieldy.

Comment 2

[Chris Casciano]

*** Bug 194164 has been marked as a duplicate of this bug. ***

Comment 3

[Josh Aas]

taking

Comment 4

[Martin Girschick]

automatically closing the window makes only sense, when the download is openend
automatically.

A little bit strange, but useful would be an option which:

a) removes items automatically if they are downloaded completely AND
[("automatically open" is ON) OR (the item is openend or shown)]
b) closes the window when now downloads are shown.

Comment 5

[Andy Boyd]

A pref option to auto-close the dl manager after successful download would be a
useful and time saving addition.  Firebird has similar options, surely Camino
could have the same?

Comment 6

[Alex K]

so glad I spent ages trolling through all the download manager bugs to see this
was already requested. I'm voting for this bug now!

Comment 7

[Josh Aas]

I'll do a patch for this for 0.9. I don't want to do it until we do the major
prefs rewrite for 0.9.

Comment 8

[Joel Craig]

Simply adding:

user_pref("browser.download.progressDnldDialog.keepAlive", false);

to the user.js does not work. There will have to be some tinkering around in the
code to get Camino to recognize this preference.

Comment 9

[Joel Craig]

Simply adding:

user_pref("browser.download.progressDnldDialog.keepAlive", false);

to the user.js does not work. There will have to be some tinkering around in the
code to get Camino to recognize this preference.

Comment 10

[Josh Aas]

correct - our dl manager doesn't know anything about that pref at the moment.

Comment 11

[Josh Aas]

done as part of pref rewrite, landed on trunk

Comment 12

[sairuh (rarely reading bugmail)]

vrfy'd fixed with 2005011808-trunk bits.