Open Bug 814000 Opened 9 years ago Updated 2 years ago
Setting a pre-defined download folder for attachments is inconsequential - almost never used in attachments UI (Attachment options > Save files to [folder] aka Browser
.download .dir pref)
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20100101 Firefox/16.0 Build ID: 20121024073032 Steps to reproduce: Windows vista. Thunderbird 17.0 Selecting a file to auto save attachments. Tools > Options > attachments > Incoming Tab select : Save files to click on 'browse' choose file and click on 'Select file' Select email and open the attachment. Actual results: After: click on 'browse' choose file so it is displayed in the 'folder' text box line and click on 'Select file' The filename selected is incorrect: C:\Users\User\Desktop\test doc dump\test doc dump if I do not select a folder to display in the 'folder' text box then the filename displayed in the 'Incoming tab' is correct. however, when I open the attachment it is not save to the selected location. It is saved to \Appdata\local\temp. I also tried: closing and reopening Thunderbird to see if this helped. It did not. this is in Config Editor: browser.download.dir;C:\Users\User\Desktop\test doc dump browser.download.downloadDir;C:\Users\User\Desktop\test doc dump browser.download.folderList;2 browser.download.lastDir;C:\Users\User\Desktop\test doc dump editor.lastFileLocation.image;C:\Users\User\Desktop\test doc dump checked..nothing has the appdata\local\temp Expected results: I would expect to select the folder name and it should display in the 'folder' text box. I would expect this to then display correctly in the Incoming tab. when I open an attachment I would expect the attachment to be save in the correct folder as shown in the incoming tab. Attachment of images provided.
Sorry forgot to mention that the correct folder should be; if I do not select a folder to display in the 'folder' text box then the filename displayed in the 'Incoming tab' is correct. C:\Users\User\Desktop\test doc dump
(In reply to Wayne Mery (:wsmwk) from comment #2) > duplicate of bug 633182 or bug 92146 anje, what do you think?
I'm not certain this is completely the same. email received with one attachment. first there is some display error when selecting folder on where to save. Will attach an image to show more clearly. These are the confif entries showing the selected folder - browser.download.dir;C:\Users\User\Desktop\test doc dump browser.download.downloadDir;C:\Users\User\Desktop\test doc dump browser.download.folderList;2 browser.download.lastDir;C:\Users\User\Desktop\test doc dump editor.lastFileLocation.image;C:\Users\User\Desktop\test doc dump However, dispite the fact that I have selected the correct place where to auto save attachments. when I select one attachment and click on 'Save' button located bottom right. The 'Save files to' which I previously set, is not used. Instead the window opens on a different file location. C:\Users\User\Photos\Family\Family Name\Ancestors In the Config Editor, I searched to locate any reference to this file location. this is the only line I could find. messenger.save.dir; Value = C:\Users\User\Photos\Family\Family Name\Ancestors So when I select to Save one attachment, it seems to be using the entry saved in: messenger.save.dir; which is incorrect.
Images shows the two methods of selecting folder which in one method does not display correctly.
(In reply to Wayne Mery (:wsmwk) from comment #3) > (In reply to Wayne Mery (:wsmwk) from comment #2) > > duplicate of bug 633182 or bug 92146 > > anje, what do you think? Bug 633182 - does not express the same issues. they ask for the ability to save attachments with a different filename from the actual attached filename, so that it shows which email sent the attachment. I can see their point, but I do not want this. My bug has nothing to do with the attachment filename itself. bug 92146 - - does not express the same issues. they would like to see an option where in a folder, they select several emails which all have attachments and then extract all attachments from all emails in one go into a specified folder. Currently, they can save all attachments only for one, currently viewed message. My bug has nothing to do with wanting the functionality of selecting multiple emails, nor extracting multiple attachments.
Poor Anje, you're absolutely right. Saving attachments to central location is totally broken in many ways, and I've commented on this elsewhere although I don't think all the bugs have been filed. At a quick glance, here's a start: 1) A normal bug here: From Options, changing the central location of "Save file to" folder setting (browser.download.dir pref) is broken. As my current download dir, options show: Save files to: [# Desktop] [Browse...] Clicking on "Browse" shows an entirely unrelated folder (not Desktop), and I doubt I've ever set that as my central download location. However, browser.download.dir pref in config editor shows that other location too (not Desktop). 2) A big design problem here: Setting the central download folder for attachments (as opposed to: "Always ask me where to save files") is almost completely inconsequential. In fact, I didn't even know I have central download folder active, as it's never used whatever you do in the UI. You have to change a lot of settings in weird ways or otherwise try really, really hard to make use of that folder from the main attachment UI, which kinda breaks the whole concept of pre-defining a central download folder. To begin with, for user who have central download folder defined, "Save all attachments" on attachment header bar should just save to that folder without asking. Otherwise, what's the point of pre-defined target folder? "Save as..." should then be optional in the dropdown. For other users, vice versa. It's not all that easy to get the UI right without too much clutter, but there's a lot of room for improvement in this corner.
(In reply to Thomas D. from comment #7) > Poor Anje, you're absolutely right. Saving attachments to central location > is totally broken in many ways, and I've commented on this elsewhere > although I don't think all the bugs have been filed. > > At a quick glance, here's a start: > > 1) A normal bug here: > > From Options, changing the central location of "Save file to" folder setting > (browser.download.dir pref) is broken. As my current download dir, options > show: > > Save files to: [# Desktop] [Browse...] > > Clicking on "Browse" shows an entirely unrelated folder (not Desktop), and I > doubt I've ever set that as my central download location. However, > browser.download.dir pref in config editor shows that other location too > (not Desktop). Problem 1) seems volatile, changing folders updated everything and seems stable, but I don't have time for systematic research. But even for a once-only, there should never be discrepancy between download.dir shown in options and the actual download.dir.
Summary: auto save attachments → Setting a pre-defined download folder for attachments is inconsequential - almost never used in attachments UI (Attachment options > Save files to [folder] aka Browser.download.dir pref)
Plus, due to bug 408647 and several other bugs in this corner, the entire attachment download experience out of the box is really bad - think of saving your attachments into your specific target folder, TB will save them there but there's no link to get into the folder - so most users will just open their file managers and navigate to the very same folder again. Grrr. For that one, Bug 907732 would be a giant step forward but TB volunteer manpower isn't made for giant steps.
(In reply to Thomas D. from comment #7) > 1) A normal bug here: We probably need a new bug for the central download folder UI mismatch problem in options as mentioned in comment 7. > 2) A big design problem here: > > Setting the central download folder for attachments (as opposed to: "Always > ask me where to save files") is almost completely inconsequential. I dwelled a bit more on that in Bug 539198, of which this might be a dupe. Perhaps we need to break up the general design problem into smaller, actionable bugs.
See Also: → 539198
You need to log in before you can comment on or make changes to this bug.