User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a1) Gecko/20051201 MultiZilla/1.8.1.0u SeaMonkey/1.5a Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a1) Gecko/20051201 MultiZilla/1.8.1.0u SeaMonkey/1.5a When a message draft is autosaving, attachment(s) should not be attached. Only when sending should attachments be attached. This is true for mimed binary attachments and for text attachments. The idea is twofold: 1. Large attachments can take a significant amount of time to mime; 2. If a draft sits in the drafts folder for an extended period, it is possible that the final version of an attached file does not make it, as an older version may have been attached to the draft. Reproducible: Always Steps to Reproduce: 1. Enable autosave every x minutes. 2. Begin composing a message. 3. Select an attachment. 4. Autosave interrupts work to mime attachment. 5. Close message composition window, without sending completed message. 6. Return to drafts folder sometime later, after attached file has been edited. 7. Send message. Actual Results: 1. Composition is interrupted by autosave (also impacted by Bug #307042). 2. Message is sent with outdated attachment version. Expected Results: 1. Autosave should be as non-intrusive as possible (see Bug #307042). 2. Message should contain the current version of an attached file when sent.

I don't mind the attachment being autosaved, but the autosaved copy should be permanently encoded and saved that way. This is how Outlook Express for Macintosh worked -- the first time you save the draft, the attachment is encoded and cached. Further requests the save the message did not re-encode any existing attachments. This saves on interruptions during each autosave.

(In reply to comment #2) > I don't mind the attachment being autosaved, but the autosaved copy should be > permanently encoded and saved that way. I don't see a real problem with this approach, however, consider the situation where the attachment might be changing while a message is in draft, i.e., a word processing document. One could draft an email referencing the attached document, attach the document, and then before sending (under the above scenario, the draft would have been saved, caching the version of the document which was current at the time of saving the email draft), the author decided to have one more look at the document to make final edits. The cached version - *not* the final version - of the attached document would then be sent with the email. While the example I cite may seem extreme, it's happened to me (I'm one of those anal retentive types who constantly goes back to look and see if that's truly the "final" version of something, tweaking this and that "just one more time" before sending. That said, I *rarely* send live word processing docs, preferring pdfs due to their static nature, however, all too many people do indeed send erstwhile dynamic content in their attachments, and I might be concerned that an out-of-date cached copy might go instead. Just some random thoughts on the subject.

What I tend to do is to attach a file, and then delete the file *before* I send the message! (Or move it somewhere else) After all, the file is attached, right? Right? It all depends on what you perceive the program to be doing -- attaching a file, or attaching a path to a file. Other times, I actually have repeatedly attached a file that I've wanted to keep changing before sending the message, so I see where you're coming from.

xref bug 378046

1 The files should be attached and encoded into the message when first saved 2 it may be argued whether or not they should re-encoded every time the message is saved (perhaps thunderbird could check whether they have been touched in the meantime) if they are still available - except the last time prior to sending (see 4) 3 if they have been deleted prior to sending or to saving the message again, then the previously cached copy should be kept with the message 4 they should certainly and _always_ be re-encoded from source (if there are chance that they have been modified and if they still exist) just before sending and most importantly: 5 Message saving should be done IN A SEPARATE THREAD, asynchronously, so as to not block Thunderbird while saving. The fact that the whole user interface of thunderbird may block for several seconds while saving the message is a separate issue, it is a plain bug (760859), and should be fixed, rather than be taken as a reason for not attaching the files.

Expectations vary as to what happens if I attach a file, and then change the original later before sending.

I mean it's important to ensure that BOTH these hold: - when you save a message with attachments, you _must_ be able to rely on the fact that that message includes those attachments - when you send a message you _must_ be able to rely on the fact that the file you send is current The fact that Thunderbird may block because saving takes a while should not be taken into account because that should not happen at all in the first place.

@David then maybe a dialog: "the attached file has been modified since it was attached. What do you want to do? Keep original attached version / Update attachment", obviously expressed better than this.

Matteo, what you propose involves some mechanism for comparing the last save timestamp with the timestamp of the attachment. This bug proposes *not* autosaving attachments when autosaving drafts. If we simply mark the draft as needing to have the attachment added upon sending, this bug/RFE goes away. In fact, that solves a myriad of issues, as there is continual disagreement over which version of a file should be sent as attachment (snapshot at the time of attaching or the latest-edited version). I have no idea, however, how to implement this for those using MAPI, as I do not use it. What this bug should *not* do is propose a completely new portion of code to monitor the state of original files or provide additional feedback to the user.

to be clear, this bug proposes rewriting the way drafts work completely. So, patches are extremely welcome.

Fair enough, David, and I don't mean to sound unappreciative of Matteo's thoughts on the matter, only that providing an additional mechanism for tracking attachment status may be a bit beyond the scope of this issue. That said, I'd welcome *any* movement on this, as I can't believe I opened this six and a half years ago, and I still find myself bumping into the issue (but obviously, it's not so big a deal for me, as I haven't worked on a patch, myself!). ;-)

(In reply to Lewis Rosenthal from comment #12) > Fair enough, David, and I don't mean to sound unappreciative of Matteo's > thoughts on the matter, only that providing an additional mechanism for > tracking attachment status may be a bit beyond the scope of this issue. That > said, I'd welcome *any* movement on this, as I can't believe I opened this > six and a half years ago, and I still find myself bumping into the issue > (but obviously, it's not so big a deal for me, as I haven't worked on a > patch, myself!). ;-) No problem, I'm just trying to set the high order bit on this discussion. Doing what this bug describes would require a lot of changes. On the other hand, detecting that an attachment has changed since it was attached or the message last saved probably would not require changing the way drafts are saved.

I understand that what I propose is in contrast with what the OP proposed, that's precisely why I wrote it: because I disagree with the original proposal. (which of course I hope doesn't and didn't sound like disrespect) The OP wrote: The problem here is twofold: 1.... 2..... Point 1 should not be considered at all, as it is only an issue because of an unrelated bug (saving is not threaded). Point 2 is _the_ point and a goog one, but I think not_saving_attachments_at_all_until_send is not the right solution. IMO the attachment should be encoded (or checked): - when the message is first saved -> definitely - when the message at last is sent -> definitely - every time the message is autosaved? -> (i was doubting but now I see that otherwise it would be inconsistent, so) yes Since users actually may have opposite expectations as to which version is sent (I always want the latest version to be sent but I understand that one may expect and want the opposite), then I think that the best option is to ask the user in case of mismatch. Let's forget for a moment about auto save. When the user explicitely saves the messages again _and_ when he finally sends it, if the file to attach has been changed or if it no longer exists, a dialog should appear asking the user whether to keep the original snapshot or reattach the current. In the case of autosave, I think the _first_ time the message is autosaved the dialog should appear (only if the file has changed, obviously), with a "remember my choice" checkbox to avoid undesired popups. Is there any drawback in this approach? The only potential weakness I see is that I'm not sure whether it is possible to 100%-reliably determine whether or not a file has been changed, but I think it is, isn't it?