Since i've downloaded TB 2.0 alpha1 (2006060504 --> 2006061911 on windows XP SP2), when i double-click on a pdf file , there is no more download dialog box which opens ... automatically, the file is save on disk ... If right-click and choose open, nothing seems happens ... seems because in fact, the file is save on disk and not opened ... pdf file is listed in properties -> preferences -> attachments with action "save to disk" ... If i choose a mp3 attachement, as mp3 is not listed in the list, i have the dialog box "choose what to do: open file with winamp or save to disk" ... In TB 1.5.0.2, pdf files was automatically saved to disk but I had, after the save, a dialog box which was open asking if i want to go to the saved folder or open the save file. in the last nighly builds of the 1.8 branch, it seems that the old confirmation dialog appairs during 1/10 of seconds and disappears immediatly. I cannot find a similar bug ... PS: In option --> Attachment, the option "save all attachment to this folder" is checked. But it was also the case in 1.5.0.2 ... It seems that the problems occurs since the download manager of firefox was introduced in TB ... but even in firefox, there is a confirmation of end of downloading ... without conformation, users believe the attachement cannot be open PS2: bug 340393, bug 203570 and all related are definitively an other problem, separated from this one ... This problem occurs also with not-forwarded mails ...

Bug 239136 --> meta bug for new download manager in TB

For me it is really annoying... So i resume: 1) option "save all attachment to this folder" 2) some extension have the option "save to disk" in properties -> preferences -> attachments --> so, open this kind of attachement save automatically the file to the specified folder, but there is no option to have a confirmation window as in firefox ... For me it is a regression since 1.5 as i didn't change the option and it worked well I want all the attachment be automatically save in a specified folder, but i want a box dialog open which tell me "attachment saved ... open file? Go to Folder?" as in firefox ... or, at least, a confirmation windows, because it is really strange for user coming from 1.5: they believe the attachment is not saved and try again and again and again :-)

I think this is a dupe of some other problems with toolkit changes to the helper app dialog on the branch.

1.5.0.9 seems to behave the same way. I'll see if newer 1.5.0.x builds fix it, but I doubt they will.

1.0 behaves the same way, as near as I can tell. Can anyone else confirm that this is a regression, and if so, what am I missing?

(In reply to comment #5) > 1.0 behaves the same way, as near as I can tell. Can anyone else confirm that > this is a regression, and if so, what am I missing? > from comment #2 >> I want all the attachment be automatically save in a specified folder, but i want a box dialog open which tell me "attachment saved ... open file? Go to Folder?" as in firefox ... or, at least, a confirmation windows, because it is really strange for user coming from 1.5: they believe the attachment is not saved and try again and again and again :-) ----------- So to resume, i've updated from 1.5 to 2.0 alpha without change the settings ... And with the new version, i double-clicked on the attachement, on nothing SEEMS be done ... i continue to double-click 2, 3, 4 times, SEEMS no result ... but in fact, the file was succefully saved in the attachement directory, but without notice ... I'm SURE that in 1.5 there was not like this: the file was automatically changed, but there was a confirmation pop-up saying that the file was saved.

Now, to view the bug do this: delete all actions in Tools->Option->Attachment-->Download Action ... and let Tools->Option->Attachment->Attachments Folder to "Save all Attachement to this folder" (and select a folder) Choose a mail with an attachement: for example a .doc file Double click --> a confirmation windows appairs Choose Save to disk anc check the box "Do this automatically for files ..." --> The file is save WITHOUT confirmation If you try again by double click on the file: same thing: no windows confirmation saying that the file is saved. === Now, do exactly the same thing with 1.5 --> after double click on the file, a dialog box appairs showing the status of save. This windows stay open with option "go to folder" or "launch the file" ==== Now, in 2.0 this status windows is replaced by the new download manager, as in Firefox ... In firefox, in Option-->Main-->Downloads you can tell "show the download manager when downloading a file" and "close it when download is ended" In thunderbird, bu upgrading from my 1.5.0.2 where the download status was showed to 2.0 alpha1, it seems thus that either "show the download manager when downloading a file" is unchecked, or "close it when download is ended" is checked ... But there is no gui option to change this ... and no menu option to show the download manager ... What I asked was that the update from 1.5 to 2.0 keeps the settings to let the confirmation windows AND add the same configuration of the download manager in option as in firefox.

i've checked now in 1.5.0.9: it works with confirmation windows i've do the test in 2.0: no confirmation by download manager In about:config i see these value browser.download.manager.closeWhenDone true (and this is the default value) browser.download.manager.showAlertOnComplete false (also default value) etc ... The only user_set values are: browser.download.defaultFolder F:\Thunderbird\Attachments browser.download.dir F:\Thunderbird\Attachments browser.download.folderList 2 browser.download.useDownloadDir true So, i presume by adding in TB 2 the new download manager of FF 2.0, this option browser.download.manager.closeWhenDone true is not update from the previous setting of 1.5

In 1.5, I had to toggle browser.download.progressDnldDialog.keepAlive to true to get it to show the dialog. Somehow it got set to false...but you're right, that has no effect in 2.0

Actually, my 2.0 build had issues (download manager doesn't compile very well for me). But toggling browser.download.manager.closeWhenDone to false fixed the issue in this bug for me. It defaults to false in TB, and there isn't UI for changing it, that I can see...

Not sure if there's anything we can do about this - if we change the default to true, everyone will see the download manager dialog whenever they save or open a file, with no option of turning it off. It looks to me like downloads.js has code for dealing with this pref, but our downloads.xul and downloads.dtd don't have UI for the pref.

Maybe setting it to true during upgrade phase if browser.download.progressDnldDialog.keepAlive is true in 1.5? I don't know if it is feasable by installer

Using browser.download.manager.closeWhenDone False works in TB 2.x in that it keeps the Download Manager visible and essentially duplicates the previous functionality. However now that I can do this I question the entire idea of moving to FF's DL manager. What's the point? You're not actually tracking *downloads*, only *saves*. And why does someone need a record of every doc they've ever saved in one window? What was wrong with the old behavior? What issue does this change improve upon or resolve, or was it just essentially arbitrary to keep FF and TB as close as possible in core function use? Although the current approach is acceptable when browser.download.manager.closeWhenDone is set to False I would still advocate reverting this to the old behavior. I just can't see any good reason to have changed it.

(In reply to comment #11) > Not sure if there's anything we can do about this - if we change the default to > true, everyone will see the download manager dialog whenever they save or open > a file, with no option of turning it off. Moving bug from an obsolete flag blocking-thunderbird2+ to blocking-thunderbird3? to keep it on the radar.

This bug was nominated for blocking-thunderbird2+ but never fixed ... This should be blocking-thunderbird3+...

Moving from wanted‑thunderbird3.0a1? flag to wanted‑thunderbird3.0a2? flag since code for Thunderbird 3 Alpha 1 has been frozen.

This isn't going to make a2.

And TB3 final? This bug was blocking TB2 2 years ago but was not fixed

Not a blocker, though I can understand it can be a bit confusing. This is the case where bug 408647 would come in handy...

Bug 408647 would at least make the workaround available from somewhere in the UI. Bug 907732 would fix this in a much nicer way...