User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.25) Gecko/20111212 Firefox/3.6.25 ( .NET CLR 3.5.30729; .NET4.0E) Build ID: 20111212142243 Steps to reproduce: attach a file change file Actual results: changed file was sent Expected results: unchanged file should have been sent

This is in response to comment 63 in bug 378046. For certain ways of attaching files, a copy of the requested file is NOT made. Consequently, the file to be attached can either change or disappear before it is sent. In bug 378046, the determination was made that TB should be changed so that a snapshot of the attachment is always made. However, bug 378046 has been around for 5 years, and has seen no activity in about 1.5 years, despite some work having been done. Until such time as it is actually fixed, I propose a partial interim solution which presumably is much easier to implement: Before sending, TB should check whether the "attached" file still exists or has a changed timestamp since the time it was attached, and if so ask the user something like: "Attachment[s] <filename> [<filename> ...] appear[s] to have changed since the time at which you attached it/them. Send anyway?" Comment 63 indicated that it could be costly to compute a checksum, so I have modified my suggestion to only look at timestamp or existence.

Note that the above references to comment 63 refer to bug 378046, not the current bug. (No doubt there was a way to make that not happen, but I don't know it, sorry.)

-1 I think this is desired behavior. Sometimes I attach a file, just to make sure not to forget it (you all know how often people forget attachments) and then edit the file to make sure it is up-to-date. I want the latest version to be sent OR to be asked which version to send.

(In reply to Hendrik Maryns from comment #3) > -1 > > I think this is desired behavior. Sometimes I attach a file, just to make > sure not to forget it (you all know how often people forget attachments) and > then edit the file to make sure it is up-to-date. I want the latest version > to be sent OR to be asked which version to send. I take this to mean that you like the *current* behavior, i.e. what gets sent is the file at the original location at the time of sending, not at the time of attaching. My reading of the discussion in bug 378046 is that the eventual patch will have the effect I want, and not what you want, i.e., the file that is sent will be the file at the time of attaching. You may therefore want to comment in that bug as well. In any case, my proposal in the current bug simply verifies that the user actually wants to send the changed version, so presumably would be acceptable to you?

As the resident attachment developer, I think I'd lean towards fixing this bug and WONTFIXing bug 378046. This bug at least has a ux-feedback benefit, whereas the other one just changes a sometimes-bad default to another sometimes-bad default.

(In reply to Jim Porter (:squib) from comment #5) > As the resident attachment developer, I think I'd lean towards fixing this > bug and WONTFIXing bug 378046. This bug at least has a ux-feedback benefit, > whereas the other one just changes a sometimes-bad default to another > sometimes-bad default. Uh, at the risk of discussing bug 378046 here, I think the primary goal of what folks wanted to do in bug 378046 was to make attachment behavior *consistent*. That is somewhat orthogonal to user feedback, and also just how to make the behavior consistent. I don't have strong feelings about how to make behavior consistent, but I do have strong feelings that I need to know if an attachment has changed out from under me before it is sent.

(In reply to peter blicher from comment #6) > (In reply to Jim Porter (:squib) from comment #5) > > As the resident attachment developer, I think I'd lean towards fixing this > > bug and WONTFIXing bug 378046. This bug at least has a ux-feedback benefit, > > whereas the other one just changes a sometimes-bad default to another > > sometimes-bad default. > > Uh, at the risk of discussing bug 378046 here, I think the primary goal of > what folks wanted to do in bug 378046 was to make attachment behavior > *consistent*. That is somewhat orthogonal to user feedback, and also just > how to make the behavior consistent. I don't have strong feelings about how > to make behavior consistent, but I do have strong feelings that I need to > know if an attachment has changed out from under me before it is sent. I should also add for the record, in partial concurrence with comment 3, that sometimes it is useful to send the changed attachment. For me, this typically occurs when I attach a file which has been modified in some program but not yet committed to disk, which I later write to disk prior to sending.

(In reply to Jim Porter (:squib) from comment #5) > As the resident attachment developer, I think I'd lean towards fixing this > bug Per Jim's comment 5, confirming this (more as a problem than as a solution). Any improvement of behaviour will be helpful, so this might be an easy start. However, it's not a solution, at all. > and WONTFIXing bug 378046. This bug at least has a ux-feedback benefit, > whereas the other one just changes a sometimes-bad default to another > sometimes-bad default. I think Jim's comment 5 overlooks a couple of things here. This bug 722094 changes nothing about sometimes-bad defaults, because as a matter of facts there are no defaults and the current behaviour, even after this bug, will still be widely inconsistent, intransparent and unpredictable. I don't have time for a systematic research, but I'll note a few obvious problem points of just doing this bug while not fixing bug 378046. It's obvious there are two competing behaviours, both in current TB and wanted by user (as explained by WADA and obvious from the whole discussion of bug 378046): A) Attach snapshot upon time of attachment B) Attach snapshot later when sending Read bug 378046 comment 60 again to see that TB currently uses an inconsistent and completely intransparent mixture of A) and B), depending on circumstances like *method* of attaching (mapi vs. non-mapi), and if the draft has ever been *closed or not* (which requires saving, but it's not triggered by saving, it's triggered by closing). The current behaviour is: - Sometimes, TB does A), immediate snapshot: For all attachments attached via MAPI. - Sometimes, TB does B), snapshot when sending: For non-Mapi attachments, but only if you never close the draft before sending. - Sometimes, TB does AB) - something between A) and B): (Even) for *non-Mapi* attachments, we suddenly take a snapshot somewhere along the way when user closes the draft, thus turning the link to a live document (B) into a static TB-owned copy half-way down the composition road. FTR, this is neither A), nor B): It's not A) (immediate snapshot) because any changes to the original file that occur between attaching and closing the draft will be accepted (without notice). It's not B), (snapshot when sending) because any changes to the original file that occur between closing the draft and sending the message will be ignored (without notice). So which problems, if any, will this bug solve? I'll refer to the proposed interim solution of comment 1, which is different from expected results in comment 0 (!). Afaics, comment 1 proposes the following behaviour (albeit as an interim workaround fix until both bug 378046 and bug 722929 are fixed): - assuming current behaviour described above in this comment (i. e. neither bug 378046 nor bug 722929 have been fixed) - get filestamp when attaching - compare filestamp when sending - upon sending, if there's a difference (or file is gone), show this msg: > "Attachment[s] <filename> [<filename> ...] appear[s] to have changed since the > time at which you attached it/them. Send anyway?" So let's check the behaviour after the "improvement" suggested by this bug. 1) For MAPI, this doesn't apply. We'll still always take immediate snapshot when attaching. So users expecting A) will be happy, users who need B) cannot use MAPI (bug 378046 and bug 722929) For MAPI, four scenarios: 1a) user changes neither original nor snapshot: TB sends immediate snapshot taken when attaching, without questions (ok) 1b) user modifies only original source file before sending: we can detect that source file is newer than attached snapshot, and offer to re-attach the modified source instead of the old snapshot. For which we need a question like: "Attachment[s] <filename> [<filename> ...] appear[s] to have changed since the time at which you attached it/them. Send newer version(s), or old version(s)?" Another problem here: How to handle multiple attachments? What if I want the old snapshot for attachment file x, but the most recent snapshot for attachment file y? A single question for multiple attachments is nonsense, but questions for each attachment require a much more sophisticated UI, unless we want to ask the question for each attachment, which might be annyoing and again, it needs more complex UI to stop the questions. So already, the "simple patch" here is no longer simple. 1c) user modifies *both* the original source file and the immediate snapshot, by opening the snapshot from within TB, editing, then saving from external program. Timestamps of both original and attached snapshot will be newer than timestamp of snapshot taken when attaching. So what do we do? I don't know. Asking questions here is nonsensical and near impossible to get them right (but imo bug 378046, especially if combined with bug 722929, will fix this problem). 1d) user modifies *only the attached snapshot* before sending. So snapshot is newer than original source, just send without questions (ok). 2) For NON-MAPI methods of attaching Users who want A) - immediate snapshot when attaching - practically cannot use Non-Mapi methods of attaching, because we are *not* taking an immediate snapshot (as opposed to Mapi-method, bug 378046). Users who want B) - snapshot when sending, will be happy AS LONG AS they don't accidentally close the draft, which will mess everything up: 2a) IF draft is never closed before sending, so opening attachment from within TB will actually open the original source file (bug 378046). User can edit the source file both from inside and outside TB, most recent version will automatically be attached when sending. This is bad for users actually expecting A), and not knowing that they mustn't use non-mapi methods, so as a warning, we could ask them (this bug): > "Attachment[s] <filename> [<filename> ...] appear[s] to have changed since the > time at which you attached it/them. Send anyway?" [Yes, send anyway] or [No, don't send modified file] If user chooses [Yes], good: we can send updated file. But what if user chooses [No]? Oh, sorry, we no longer have a snapshot of the file in the state when it was attached... please undo all modifications done to the original, and sorry for not telling you in advance that we never went to take a snapshot when you attached the file... :( Back to bug 378046: It's inconsistent, intransparent, and unpredictable, even dataloss! Moreover, just asking the question as proposed by this bug doesn't help anything for users rightly and naturally expecting A) - immediate snapshot -, which is what all webmailers out there also do, afasik. (I'm not denying that B) is a legitimate RFE, and we ultimately need both A) and B). Moreover: We have nothing to offer if original file is deleted or the (removable/network) media from which the file was attached is no longer connected. Back to bug 378046, comment 60, which explains in detail why we need to make the default behaviour A) unless we properly and fully implement A) AND B) as two alternative behaviours. 2b) NON-MAPI, IF draft is ever closed before sending, - surprise - suddenly we take a snapshot, which is then static for good. So until closing, we keep a live link, then suddenly, we create a static snapshot which can be modified only from within TB. This is bad for both types of users: * for users expecting A), this is bad behaviour because changes to original source will go into the attachment until the draft is closed, and, worse, we don't take an immediate snapshot so the initial version is irretrievably lost, as in 2a) above, in case of [No]. So again, the simple question proposed by this bug doesn't help without further changes of behaviour. * for users expecting B), this is bad behaviour because any changes of original source after closing the draft will no longer go into the attachment. Well, I suppose could ask them as we still have both versions. But: After closing the draft, we have the same 4 scenarious as described above in 1a)-d) for MAPI, only with added confusion because of our behaviour before closing the draft. (I'll skip the details here). Conclusion: - this bug, per it's current proposal in comment 1, will alleviate only a very small fraction of problem cases - it is impossible to get the questions right until we fix bug 378046, at least. - Ultimately, we need both bug 378046 and bug 722929 to serve users expectations of A) and B) as clear and strictly separate alternatives of behaviour. - Nominating bug 378046 for wontfix and declare this bug to be the cure is absurd and ignores the current complex reality of TB's behaviour - As shown above, fixing this bug 722094 will NOT make the behaviour consistent or predictable, so contrary to comment 1, "sometimes-bad default" will not go away by fixing this bug. As a side note, users who really and reliably want B) - attach when sending - can currently use the attachment-reminder feature as a workaround, whereas there is practically no workaround from within TB for users reliably wanting A) unless they use MAPI only.

(In reply to Thomas D. from comment #8) > (In reply to Jim Porter (:squib) from comment #5) > - Nominating bug 378046 for wontfix and declare this bug to be the cure is > absurd and ignores the current complex reality of TB's behaviour > - As shown above, fixing this bug 722094 will NOT make the behaviour > consistent or predictable, so contrary to comment 1, "sometimes-bad default" > will not go away by fixing this bug. Typo: contrary to comment *5*, "sometimes-bad default" will not go away by fixing this bug. Fixing bug 378046 *only* in the limited sense of A) "immediate snapshot when attaching" the default behaviour will - fix a lot of problems including dataloss and sending of wrong data - make the behaviour consistent, predictable and transparent - make the behaviour ux-consistent with webmailers - remove an incompletely realized and unpredictable "feature" of B) "snapshot when sending" Imho, that's much more than replacing a "sometimes-bad default" with another "sometimes-bad default". We cannot remove feature A), if only because that's what other webmailers do, and for a lot of other reasons (see bug 378046, comment 60, 4a-d), including the scenario of this bug that attached files can change or disappear. So if we want to offer B) as a complementary *alternative* behaviour, good, then we need *both* A) and B), so we need *both* bug 378046 *and* bug 722929.

(In reply to Thomas D. from comment #8) I need to add that I have analysed this from a POP3 perspective. IMAP might pose additional challenges to getting both behaviours A) and B) right. And I'm not saying that we have already fully defined all the details of good behaviour for A) and B). I'm only saying current behaviour is definitely bad.

Bug 391190 outlines same/related problem for attached messages etc. from inside TB's mail folders.