Open Bug 1387292 Opened 7 years ago Updated 2 years ago

Attachments appear on my desktop when I open them and stay there even though I reboot. [Mac]

Categories

(MailNews Core :: Attachments, defect)

Product:
MailNews Core
Component:
Attachments
Platform:
Unspecified
macOS
Type:
defect

Tracking

(Not tracked)

Status:
UNCONFIRMED

People

(Reporter: u599626, Unassigned)

References

(Regression,
URL
)

Details

(Keywords: regression)

User Story

From https://support.mozilla.org/en-US/questions/1169946#answer-993089

This has been an ongoing report in support for all the years I have been involved with Thunderbird.  But I have never seen a true "solution"  only workaround like this.  Almost certainly this but is "invalid as it is probably an operating system issue,  but from a support perspective we need to know how to fix it.

1) In the Finder, open the Go pull down menu. 
2) Select Go To Folder at the bottom. 
3) A window will open up. Enter /private and hit the Go button. 
4) Find the folder called tmp, and make an alias of it. 
5) Move the alias to your desktop. 
6) Go to any location you like (I went to Library/Applications) and create a folder. I called my folder Thunderbird Temp Space. 
7) Place the tmp alias in that folder. 
8) Open Thunderbird's Preferences and select Attachments. 
9) At the bottom of the attachments window, select the Save Files To button, and then hit the Choose button to tell it where to save the files. 
10) Find and select the tmp alias you created. You will now notice that the window next to Save Files To says /private/tmp.
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170628075643

Steps to reproduce:

Open any email attachment.


Actual results:

Attachment opens in appropriate application, but is saved on my desktop.  These files do not go away.  They stay there clogging up my desktop.

I discovered that even by changing the "Save file to" location (in the Attachments Preferences) from Desktop to somewhere else prevented them from piling up on my desktop, but they still pile up in that new location.  I should also point out that this happens even though the "Saves files to" button is not selected (I have the "Always ask me where to save files" button selected.

My workaround was to change the "Save files to" the hidden tmp folder, as this is always cleared on each reboot.  No more accumulating files.


Expected results:

Open the files from the tmp folder.
URL: https://support.mozilla.org/en-US/que...
User Story: (updated)
OS: Unspecified → Mac OS X
Adding some MACsperts + Jorg
Component: Untriaged → Attachments
Product: Thunderbird → MailNews Core
Summary: Attachments appear on my desktop when I open them and stay there even though I reboot. → Attachments appear on my desktop when I open them and stay there even though I reboot. [Mac]
Version: 52 Branch → 52
seems this is not new...

The grand-daddy is 
Bug 238789 - Opening attachments should not also save copy to desktop
blocked by 
Bug 311292 - Can't specify download location of temp files on Mac - a core bug, which has LOTS of duplicates

Then we also have
Bug 542694 - Location to save opened attachments is difficult to set
Bug 706189 - Attachments save copy when clicked bypassing save option
Indeed, a very very old bug.
I published my preferred workaround about two years ago in the MozillaZine forum:
http://forums.mozillazine.org/viewtopic.php?f=39&t=2925221&p=14097695#p14097695

and four years ago in the French Mozilla forum:
https://forums.mozfr.org/viewtopic.php?p=727913#p727913
I disagree that this is a bug: this is working exactly as designed.  Perhaps for some users, they wish it were designed differently, but I'll say that personally, I prefer and would totally expect the currently designed behavior.

In order to open an attachment in an external application, TB has to write the attachment file to disk.  You can control where it writes the file.  There is no notion of saving a file temporarily for the purpose of opening it in an external application: it is not possible to know when the external application is done with the file, and removing the file before the application is done with it will result in problems, as well.

The semantics of "opening" a file attachment from an email is simply a two step process that's done in serial for the user's convenience: (1) Save the attachment as a file, then (2) Open the file using the associated application for the file's type.

The operation of "Saving an attachment as a file" correctly implies saving it permanently, to let the user then decide what to further do with the file (e.g., delete it, move it elsewhere, open it, and so on).

If you want to choose to have TB save these files to a location that the OS will clean up (e.g., /tmp aka /private/tmp), that's your choice as a user.  But, the expectation correctly is that TB saving file attachments is a permanent operation, not a temporary one.  If you want file attachments opened to be deleted after you're done with them, it's the user's (not the TB application's) responsibility to dispose of those files.  TB cannot "magically" know when you're done with them.

Choosing to save the files to a location that gets purged on reboot can lead to really unfortunate experiences, too.  For example: you receive an email with a file attachment.  You open the attachment (save it, launch application that opens the file).  Now with the file open in the external application, you delete the email.  Now, the only copy of the file attachment is the file in your temporary folder.  While using the file in the external application, your computer crashes, resulting in a reboot, and thus, purging of the temporary folder and the file in it.  You've now lost the file, entirely.  This is a poor design.

Any design that results in data loss in the event of unexpected abnormal termination of the program, the operating system, etc., is a bad design.

Personally, I have a (permanent) folder where I have my browser and TB save files to.  I sort the files by last modified date.  I can easily purge old files from the folder, or if I need them, copy them out to their permanent homes.  I don't worry about losing any of these files in the event of an app crash or system reboot.  They don't result in clutter because I can easily delete old files with a Click/Shift-Click/Delete workflow, very quickly.

Anyhow, I vote for WONTFIX: this isn't a bug.
I can't add any wisdom here and I'm not a Mac user. Yes, opening the attachment will save it somewhere to the file system, typically in some sort of system dependent "temp" directory. The files stay there and it is good housekeeping to purge the temp directory every once in a while. Other programs also dump files in there, not only TB.
If you save your email (as I do), the attachment doesn't go away.  In every email app I've ever used, it is understood that you either purposely save the email, or the attachment, or both, but if you don't save it, and delete the email, you didn't want the attachment, and it's gone.  It may be that other email programs open these files in some folder the user is unaware of and never purges them, but if you don't know where they are, how does it help you?

As with most things, there is no correct answer here.  However, I do think it would be helpful to easily give the user the option to make it work either way.  At the very least, if the "Save files to" button isn't selected, and the window and button to select a location change their color saturation, that indicates to me that they won't have any affect . . . but they do, in the current app.
There is an issue in that the behaviour is not consistent across platforms,  and in this case there is no real reason for a lack of consistency.  

But saving a file and viewing it are two distinct actions in the mind of the user. (we even see complaints that changes made while viewing are not saved, based on the expectation of the attachment being "a file")  

Folk are not asking for a file,  but in most cases something they can read.  They are quite happy with the "file" as being in Thunderbird as an attachment and if they do want to save it they click the save button.

Even on windows our behaviour is questionable,  they open the file and we offer to open it of save it,  just in case they made a mistake in double clicking I assume.  Despite putting a visible save button in the attachment pane
So, duplicate of bug 238789 ?
And comment 4 applies to that bug?
I originally posted a request for help on solving this problem on the Mozilla Support Forum.  Matt responded and provided me a clue that allowed me to find a solution (thanks again, Matt).  I then shared my solution on the forum.  Matt then asked me to report this on Bugzilla.  I did this without knowing the history of this issue.  But, if I had known this was a 14 your old thread with divided opinion as to whether this is even a bug or not, I never would have started this.

The bottom line here?  If a particular operation in a piece of software hasn't changed after 14 years, it isn't going to.

I'm sorry I brought this up.  Bye.
Relevant and related links regarding Apple's own Mail.app behavior regarding file attachments:

https://www.lifewire.com/stored-attachments-from-os-x-mail-1172807
http://hints.macworld.com/article.php?story=20130515071439989
https://support.apple.com/kb/PH19154?locale=en_US

Mail.app also writes opened file attachments to the filesystem, as it must do in order to open them in an external application, but it does it in a non-obvious location.  They provide a configuration option, "Remove unedited downloads", to affect Mail.app's behavior to clean up this temporary cache for file attachments.

Maybe TB could pursue a similar approach, and that would please more TB users?  I don't know how feature requests are managed for TB, but that sounds like a reasonable thing to do.

Also, I'd like to point out that writing to /tmp can be a potential security risk in multi-user environments, unless file permissions are carefully managed and race conditions are avoided.  I suppose most Mac users are, for all intents and purposes, operating in a single-user environment, but the application's design should be safe for multi-user environments -- which is why Mail.app writes to a location in the user's home directory, instead of system-wide temporary directory like /tmp.
This behaviour is what I would class as a user experience bug in that the current behaviour is unexpected to me based on my experience with other software over the years...and this behaviour doesn't feel like an improvement over the learned experience...hence a UX bug.  :)

MacOS 10.10.5
TB: 52.4.0 (64-bit)

My incoming Attachments preferences says: "Always ask me where to save files"
However every time I open an attachment (e.g. to preview a PDF) I end up with that attachment saved to my Desktop without any prompting.

This annoyed me enough over time and I finally had some minutes and decided to look for a solution which led me here.

If I open a file, I haven't given any indication that I want it sitting around my filesystem permanently waiting for me to clean it up.  I don't want to change my default save location to a temp directory because when I want to save an attachment I want to save it (ie not temp dir).

Here is rephrasing of the above example... 
I receive an email with an PDF attachment.
I open the attachment (e.g. PDF file saved _somewhere_, file opened in Preview app).  
I see it isn't anything I care about so I just close Preview app.  
Preview doesn't complain which implies there haven't been any changes made that need saving...but from a user perspective I opened the file...I didn't save it...so I don't have the expectation that it is saved somewhere (except for years of conditioning from using Thunderbird with this bug :))  Even if I do "save" (not save as)...where am I saving to?  Doesn't make sense since I opened the attachment from thunderbird...no context about where the attachment file is.
-OR-
I see the attachment is an invoice I need to save to a specific location, so I either do a save-as from preview or I switch back to thunderbird and save the attachment from there.

I get it that if a user uses open as a proxy for save (conditioning due to this bug?)
and don't save the attachment in any other way (ie via thunderbird or save-as from program)
and they delete the email...

...they will lose the file once the temp files are gone.  Even if the temp file isn't deleted, they will have a lot of trouble finding the temp file again after they close the viewing program.  Is this really a common user behaviour?  

I don't think anyone is insisting that Thunderbird should use system temp or user temp for these files.  A solution that might allay both the bug and some of the above concern could look like the following:

- when a user opens an attachment (not saving)
- thunderbird saves attachment to a thunderbird-specific temp directory without any prompting (completely independent of save preferences).
- thunderbird periodically clears out temp files in this directory based on (now - last_accessed_time) > X

If you want an option for backward compatibility for users, you could add an option to the attachment preferences saying:

[ ] Save attachments when opened?

If checked the open flow can be kicked to to the save flow (ie prompt for location or save to default) before opening the file.  Otherwise just use the new tmp scheme described above.  This option could be checked by default for updates and unchecked for new installs...or checked for everyone...I'd just be happy to have a fix.

If this doesn't get fixed, I should at least get prompted per my preferences "where do you want to save this attachment" every time I open an attachment from thunderbird.
The facts are:
- To view an attachment in an external application, you need to save it as a file.
- Thunderbird doesn't know when you're done with viewing, so it can't deleted the file.

Usually files are saved to a temp directory, not your download directory. Why do temporary files end up on your desktop, that's the question here. I have set my download directory to the Desktop, yet an attachment is saved to a temp directory for viewing.

The only think TB could do is periodically purge temp files. That's a little hard since it doesn't keep track of all the attachments it saved. That would be an enhancement.

At least on Windows it's good housekeeping to periodically clean-out your temp directory since TB also leaves other artefacts there.

Richard, on Mac, please set your downloads directory (options, attachments, incoming, at the bottom) to the Desktop. Then open an attachment. Where does it get saved for viewing? To the Desktop or some temp directory? On Windows it goes to a temp directory (otherwise I'd have my desktop cluttered with stuff).
Flags: needinfo?(richard.marti)
Default is desktop, so no need change it. And yes, the attachment, an image, is saved on the desktop to show in the preview and stays there after closing the preview and TB.
Flags: needinfo?(richard.marti)
That's pretty rotten. That doesn't happen on Windows. So some Mac developer (which we don't have) would need to fix that.
Maybe Ravi.
Flags: needinfo?(foss)
I would say, this is a toolkit behavior as also FX saves the files and doesn't delete it after showing.
Yes. From what i could see in code, Thunderbird is using /toolkit code to interact with attachments and that source code is managed by Mozilla.

Thank you for adding me here, Jorg, but I am unable to help here.
Flags: needinfo?(foss)
So to sum up...

1) The behaviour on Windows and Mac is different.  On windows when you "open" instead of "save" the file is saved to a temp directory and then opened.  On the mac when "opened" the file is saved to whatever the default save location is (even if you have selected "ask me where to save" in preferences).

2) This logic is implemented in a library/toolkit maintained by Mozilla...so the TB team isn't in a position to address this.

3) So the work around is:
- open preferences > attachments > incoming
- select "save files to" radio button
- change the default file saving location to be a temp directory (e.g. /tmp which gets cleared at reboot) or some less annoying location than the Desktop (e.g. ~/Documents/Thunderbird-autosave).
- re-enable the "always ask me where to save files" option if you like.

Downside of the work-around:
1) If you use "ask me where to save", the default location thunderbird will open the directory chooser to will be the temp folder which might require more navigation to get to your destination of choice.
2) If you use "save files to" then all your files will always be saved to the temp folder whether you open or save...which is definitely confusing.

Sound about right?

I am not familiar with the internal TB component architecture and don't know which toolkit/lib is responsible...but if someone wants to point me in the right direction I can find the right place to report this issue and be a squeaky wheel over there.  Thanks!

I think bug 454242 probably "regressed" this, though if we ever change it, it would need thinking about a lot as to the various reasons (e.g. read the first comment there & the surrounding ones).

A workaround is to set go into Preferences -> Advanced -> General -> Config Editor, acknowledge the warning, then find "browser.download.folderList", double-click it and set it to 1.

Then all the files will be saved in the downloads directory.

Regressed by: 454242
Keywords: regression
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.