User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.9.0.3) Gecko/2008092416 Firefox/3.0.3 Build Identifier: 2.0.0.17 (20080914) When I save attachment file(s) in thunderbird, somehow a blank download manager window appears, but since it is blank, it is useless(!). The saving itself has succeeded. I don't know why the download manager window appears. Was it intentional? If so, I think we should show the file name, etc. inside the download manager window. Currently it is useless, and servers no purpose. I wonder if this "blank" download manager window appears only on my machine. Reproducible: Always Steps to Reproduce: 1.Save an attachment file of a message. 2. 3. Actual Results: A blank download manager window appears. Expected Results: If a download manager window should appear after saving an attachment file or files, I would expect the window to contain the filenames, etc.. I will attach a PNG file that shows the situation later. I don't know if the font (size, color) used in the download manager is screwed up.

Anyway, I am attaching a PNG file above. The large horizontal window in the upper left corner is the download manager window. (In mozilla, when I download something usually the filename, progress is shown. But here in TB, nothing is shown. Useless.) I wonder if the following bug is the same as my own report or not. Bug 439884 - Thunderbird Download window problem But in that case, the report mentions an external (web?) site. In my case, it is a saving of an attached file to a message that is already received. It has been like this for several months if I can recall correctly.

No, bug 439884 is actually talking about the unknown content type dialog that you get when you try to open an attachment. Your "Expected Results" would be a duplicate of bug 408647, though I suspect what you mean instead is that you don't want to see a dialog at all when you are saving an attachment from a local message, even if saving it takes just long enough that the download manager wants to open.

(In reply to comment #2) > No, bug 439884 is actually talking about the unknown content type dialog that > you get when you try to open an attachment. > > Your "Expected Results" would be a duplicate of bug 408647, though I suspect > what you mean instead is that you don't want to see a dialog at all when you > are saving an attachment from a local message, even if saving it takes just > long enough that the download manager wants to open. Well actually, I am not opposed to see the download manager open as long as it contains the filename on which I can click to access it or open the folder/directory where the file was saved. As of now, there are no items shown in the download manager window (see the attached figure) so that it is not useful at all. It would be handy to lookup the saved attachment now and then. I wonder how difficult it is to record the name of the file, directory, etc. and show it in the download manager. (BTW, is the same code / UI used for saving an attachment of a message in mail folder with the general-purpose donwload manager?)

Ishikawa, Robert, do you still see this in v3.1?

(In reply to comment #5) > Ishikawa, Robert, do you still see this in v3.1? I use 3.0.6 and I no longer see this problem. Instead, while downloading, a progress window appears, and that window works properly. In addition, the download completes properly. - Robert

(In reply to comment #6) > (In reply to comment #5) > > Ishikawa, Robert, do you still see this in v3.1? > > I use 3.0.6 and I no longer see this problem. Instead, while downloading, a > progress window appears, and that window works properly. In addition, the > download completes properly. - Robert I use TB 3.1.1, and it works properly IF you double-click on the attachment. If you right-click on the attachment and do "Save As", however, the file never appears in the download window.

I use the Mac version, no. 3.0.6 and when I right-click and do "Save As", it works just as I described, with no problems whatsoever.

(In reply to comment #5) > Ishikawa, Robert, do you still see this in v3.1? Hi, my post was more than 1.5 years ago. I use a few version. The windows version which I am using on one PC (TB 3.1.1), if I double click using LEFT button, a small whitish window appears briefly then disappears. (It doesn't stay. But I think the file name is there. Since it disappears quickly, it is hard to say, though.) This is for a small PDF. If I use "save as", a download window familiar in FIREFOX appears and then again disappears very quickly. Under linux, I have debugged a problem of TB3's failure to report that the saving of an attachment is aborted due to missing write permission to the save folder (or that the save folder doesn't exist at all.) See all the gory details in - Bug 567585 TB3 fails to raise an error when it tries to save an attachment to write-protected directory. (double-clicking case.) - Bug 429827 Download manager does not warn when its download location does not exist or is write protected (Original bug entry but the list of posts now too long to handle.) - Bug 549719 - Should UNIFY/MERGE the two different code paths for saving an attachment in a message (This may be important in the context of the current bug entry.) To make a long story short, totally different code paths are invoked when you double click on an attachment or use "save as" to save an attachment. (Bug 549719) This observation may be relevant here. - double click using left mouse button ... nsHelperAppDlg.js is invoked, and this code is shared among browser and mailer, and I think its main use is for browser: it uses BROWSER default save directory path and that is why download progress is shown EVEN FOR AN ATTACHMENT ALREADY in LOCAL user folder (!). I use pop3 server and didn't try IMAP setting. - save as ... this invokes mailer specific routine. Maybe this is why a download manager box is shown a la Firefox under windows? (I don't think download manager -like box is shown under linux. But maybe I tried so many failure cases due to missing write-permission, I forgot the normal case behavior :-( ) Both paths had a problem of not showing the error dialog when saving an attachment failed due to file system failure, but "save as" seems to have improved in 3.2a1pre. "save as" shows error dialog TWICE when the saving fails. So I am not surprised that "Save As" doesn't show the filename download window (comment 7) Hmm. That observation may not be quite compatible with mine. comment 8: I am curious to learn that Mac version doesn't seem to have strange problem(s). Can you see what happens if you create a write-protected directory and try to save an attachment to it by using either double clicking and using "save as"? I am curious. I can only say that when two different code paths are involved, we need to clearly qualify which methods have been used. Sorry, I myself have failed to say exactly which paths/methods was used in my original post here. But one would expect that a same path is invoked after all. TB3 fails user expectation here. I must have used "save as", but I can not be sure now. BTW, Bug 429827 were full of confusion due to the fact people didn't realize the different code paths were invoked and that different default save directories were used based on the different code paths. (OK, maybe it was only me who got quite confused, but in any case, no satisfactory solution has been found yet.) I think this sate of affairs can be called a mess.

(In reply to comment #9) > (In reply to comment #5) > > Ishikawa, Robert, do you still see this in v3.1? > > Hi, > my post was more than 1.5 years ago. > > I use a few version. > > The windows version which I am using on one PC (TB 3.1.1), [...] On my other machine(s), I use linux version. With TB 3.1.2 (under linux), saving the same PDF files both by double-clicking of left buttons, or using "save as" both creates a whitish box for a short while and it disappears quickly, and for these, I don't think I see the filename or anything like this. (But again, it disappears very quickly, but definitely I don't download manager like box I saw under windows. Windows XP SP3 to be exact.) There seem to be a few differences between windows and linux version, then.

(In reply to comment #10) > > With TB 3.1.2 (under linux), saving the same PDF files both by > double-clicking of left buttons, or using "save as" both creates a > whitish box for a short while and it disappears quickly, > and for these, I don't think I see the filename or anything like this. > (But again, it disappears very quickly, but definitely I don't download manager > like box I saw under windows. Windows XP SP3 to be exact.) > > There seem to be a few differences between windows and linux version, then. Well, no the difference is bogus(!). The download manage doesn't seem to have the time to get displayed fully unless the save time is longish. Today someone sent me a 3.6MB PDF attachement. When I saved it using DOUBLE-CLICKING on it the download manager appears, and the filename of this PDF is displayed at the top, and eventually when the conversion from MIME to binary data on the disk is proceedings, OTHER filenames that were downloaded before(?) appeared below, but then the download-manager window disappears. (It may be very useful to have it stay as in firefox.) "Save As" also produced the same download manager like window when I saved this 3.6MB PDF. So the behavior (or perceived visual behavior) depends on the size of the attachment. Very tricky. AT LEAST, the window does NOT stay any more in the TB V3 version.

Reporter, do you still see this problem when using a current version of thunderbird? And if you do not, please close bug report by changing resolution to worksforme

The download manager like window still appears if I click on the attachment (double-clicking) briefly after I confirm the download filename, and then it disappears. I noticed one thing: I have not properly associated .docx extension file type, and in that case, suppose I have file attachments with .docx extension, and if the double clicking on the first file fails due to unassociated filetype and and error dialog appears, and the download manager-like window stays open. (This doesn't happen if there is only one attached file in the e-mail.) Oh, the window in both cases (that disappears and stays open), seems to contain the filename. (The above is under the Windows OS. 9.0.1) Looking at the staying download-manager-like window, it occurred to me that what TB needs and what would make me comfortable would be the addition of the capability to invoke this download-manager like window so that one can verify under what directory, and what name one has saved an attachment. I will try to upload the screenshot of the staying download-manager like window, and check with the latest 10.0.x version under windows, AND linux version. Then I may decide what to do: maybe close this bug report and instead submit a feature request to invoke the download-manager like function from TB.

Checked the operation under linux. v 9.x.y under linux showed blank download manager like window. However, V 10.0.1 TB DID show a download manager like window with the filename and a few history entries during the same session. I am attaching the screenshot for this. However, as I mentioned in the previous comment, the user would like to know the folder/directory name where it is saved sometimes, and especially when an attachment is saved by mistake to an unexpected place, one needs to figure out WHERE the previous saving occurred. So a download manager like UI is useful. I found another bugzilla entry: Bugzilla@Mozilla – Bug 669615 Feature request: Downloads window not sure exactly what the request was there, but I think we seemed to generally require a menu to recall such download manager like UI with the previous history of saving. Since as far as the processing invoked by the double-clicking on the attachment, or the left-click on the attachment seem to be shared between TB and FF, it may not be that difficult to implement this.

This screen image was captured while a series of attachment t{1,2,3,4}.txt attachments were once saved, and then again resaved using "Save all" and while the prompting for confirmation for overwriting appears, the window stays open in the background: the window disappears quickly and so it is difficult to figure out what strings are inside. It may be desirable to have a menu to call this download manager like window so that we can keep track of the attachment savings in this session or even in the previous session.

I am closing it, but as I mentioned in the comment to Bugzilla@Mozilla – Bug 669615 Feature request: Downloads window I wonder what the key combination to bring up the download window manager under linux and Windows (no Command key under the OSes.) Also, as 669615 comments say we want to have a longer history record of saving information.