This is spin-off of bug 532395 comment #42. This is also report of phenomena what was observed in duplication test of bug 766495. If Offset of replied-mail/forwarded-Inline-mail/previous-draft-mail is altered while mail composition/editing, Send/Save can't find image data in the original mail then Tb spins with "Attaching...", when the original mail is HTML mail with embed image. [ Problem Detail ] As reported by bug 453196 and by bug 532395 comment #18, if original mail of Reply, Forward, is deleted while mail composition, following problem occurs. (Case-0) Original mail is deleted (bug 453196) - Original HTML mail with embed image UID=uuu (Oreder Receved column value, if IMAP folder) Offset=uuu (Oreder Receved column value, if local mail folder) Part=1 : multipart/related Part=1.1 : text/html, <img src="cid:cid-of-an-image"> Part=1.2 : image/xxx, Content-Id: <cid-of-an-image> - Image location of the image by Reply/Forward in inline(HTML mode). > imap://user-id@imap.gmail.com:993/fetch%3EUID%3E/INBOX%3Ennn?part=1.2&filename=EmbedImage.jpg > mailbox:.../Inbox%3Ennn?part=1.2&filename=EmbedImage.jpg If the original mail(UID=nnn or Offset=nnn) is deleted & expunged(by Compact) before first Save as draft, or before Send Later/Send without save as draft, mail of UID=nnn/Offset=nnn can't be obtained. If this happens on embed image of HTML mail with cid: URL, Tb looks to wait forever with "Attacching..." message. If Compact happens on local mail folder, similar problem to Case-0 can occur, because "Offset change by Compact" is identical to "Delete" for image location of embed image in HTML mail. (Case-1) local mail folder, offset of original mail of Reply/Forward Inline is altered by Compact while composing - Original HTML mail with embed image in local mail folder. Offset=nnn (Oreder Received column value, if local mail folder) Part=1 : multipart/related Part=1.1 : text/html, <img src="cid:cid-of-an-image"> Part=1.2 : image/xxx, Content-Id: <cid-of-an-image> - Image location of the image by Reply/Forward in inline(HTML mode). > mailbox:.../Inbox%3Ennn?part=1.2&filename=EmbedImage.jpg > A > | > +--- Offset of original mail in local mail folder If data at Offset=nnn of Inbox is changed by Compact of Inbox or Delete of the original mail+Compact of Inbox, one of next occurs. (Case-1-A) data at Offset=nnn : mail data doesn't exist (file size after Compact<nnn) => Attaching... (Case-1-B) data at Offset=nnn : mid of different mail => Attaching... (Case-1-C) data at Offset=nnn : valid/different mail (Case-1-C-i) the valid/different mail doesn't have part=1.2 => Save error, null image part data, and so on (Case-1-C-ii) the valid/different mail has part=1.2, but non-image part => image part data is broken(wrong data is attached) (Case-1-C-iii) the valid/different mail has part=1.2, and valid image data => image data of different mail is silently used by Tb If same thing as Case-1 happens on Edited draft mail in local Drafts folder, same problem as Case-2 occurs on draft mail. (Case-2) local Drafts folder, offset of edited draft mail is altered by Compact while editing. - Edited draft HTML mail with embed image in local Drafts folder. Offset=nnn (Oreder Received column value, if local mail folder) Part=1 : multipart/related Part=1.1 : text/html, <img src="cid:cid-of-an-image"> Part=1.2 : image/xxx, Content-Id: <cid-of-an-image> - Image location of the image by Edit draft(HTML mode). > mailbox:.../Drafts%3Ennn?part=1.2&filename=EmbedImage.jpg > A > | > +--- Offset of original mail in local Drafts folder If data at Offset=nnn is changed by Compact Folder, same phenomena as Case-1 surely happens. (Case-2-A/Case-2-B) No need to write again, because same as Case-1-A/Case-1-B. (Case-2-C) data at Offset=nnn : valid/different draft mail (Case-2-C-i) the valid/different draft mail doesn't have part=1.2 => Save error, null image part data, and so on (Case-2-C-ii) the valid/different draft mail has part=1.2, but non-image part => image part data is broken(wrong data is attached) (Case-2-C-iii) the valid/different draft mail has part=1.2, and valid image data => image data of different draft mail is silently used by Tb Many comments in bug 532395 sound report of (Case-2-A)/(Case-2-B), and some comments sound report of (Case-1-A)/(Case-1-B). bug 799450 is for (Case-2-c-ii) is phenomenon of and . bug 766495 is for (Case-2-c-iii). Note: If "Forward as attachment", attached mail is pointed like next. > imap://user-id@imap.gmail.com:993/fetch%3EUID%3E/INBOX%3Euuu > mailbox:.../INBOX%3Ennn > mailbox:.../Drafts%3Ennn In this case, forever "Attaching..." due to Compact was not observed. "No data in messae/RFC822 part" was observed instead. Forever "Attaching..." looks embed image of HTML mail only phenomenon.

This bug is a special case of bug 532395. As I mentioned in bug 532395 comment #80, I have the bug of hanging with "Attaching..." when trying to save or send draft message when there are embedded inline images in the original mail being forwarded to or replied to, but it's not any of the three cases described above in bug 817245 (not case-0 since the original mail is not deleted, and not case-1 and case-2 since there is no compacting at all, neither manual or automatic - I have autocompact turned off - ). So bug 817245 is a special case of bug 532395.

(In reply to François R-Champigneul from comment #1) > This bug is a special case of bug 532395. Have you read following in comment #0? > This is spin-off of bug 532395 comment #42. There are too many comments on different phenomenon in that bug. (A: Specific-case-1) bug 532395 comment #18 == bug 453196 because of "delete of original" case, this can occur on IMAP folder too. if draft mail is intentionally deleted while editing the draft mail, this case happens. (B: Specific-case-2) bug 532395 comment #42 on local mail folder due to Compact == this bug(bug 817245) (C: apparently-not-this-bug-and-not-bug-453196) contention between "draft delete after send" and "draft delete by auto-save" is suspected. (D: Not-clear-yet-problems) many of them sounds local mail folder & draft case, but still not so clear. (E: apparently-different-from-any-of-above) Is bug 532395 for any case of "attaching..."? I simply separated above B:, a specific case, in order to make "continuing analysis of C:/D:/E: in bug 532395" easy, in order to bring specific A:/B: out of chaos in bug 532395. If your case of bug 532395 comment #80 is different from bug 532395 comment #42(==this bug) and bug 532395 comment #18(==bug 453196), it simply means your case is not above specific A:, not above specific B:. There is no need to add comment to this bug on different phenomenon from this bug.

FYI. How to see "Image location" : At HTML mode composition window, select a image by single click, double click the image or Format/Image Properties.

(In reply to WADA from comment #2) > Is bug 532395 for any case of "attaching..."? Currently, probably yes. But I think what we should do is create a new Meta/Tracker bug (to sideline the cesspool of bug 532395) to collect *all* cases with symptoms of "Composition with inline images fails with 'Attaching...'". Then we can just add them there for ease of tracking, even without further analysis. That Meta bug should not include analysis. Analysis could still be continued in bug 532395 if needed, or in another new Meta-Analysis bug starting with Wada's comment 2. Also, we need to find somebody who is able to fix the two known cases (bug 453196, this bug 817245). I find it rather pointless and time-wasting to analyse every single report while most/many of them would probably go away by fixing the known problems. Causes not covered by bug 453196 and bug 817245 will be *much* easier to track down and analyse *after* those two known issues will have been eliminated as causes.

(In reply to Thomas D. from comment #4) > (In reply to WADA from comment #2) > > Is bug 532395 for any case of "attaching..."? > Currently, probably yes. I've changed bug summary of that bug to generic-like one, for ease of duping of unclear "Ataching..." reports, for ease of using that bug as pseudo meta bug to collect *all* unclear cases with similar symptoms. Recently, I was aware of that opener of Bug 793645 had closed his bug as dup of bug 532395 by himself. I'll close unclear reports on "Attaching..." phenomenon, what are currently held in dependency tree of this bug by me, as dup of bug 532395, in order to keep this bug for specific case clean.

I've done it.

(In reply to Thomas D. from comment #4) > Also, we need to find somebody who is able to fix the two known cases (bug > 453196, this bug 817245). As written in bug 453196 comment #5 on 2009-03-26, developers are already aware of cause. Problem is "what should be done to resolve issue" is not determined yet, and needless to say, "who can/will implement the solution if the what will be determined" is always a biggest problem. > Causes not covered by bug 453196 and bug 817245 will be *much* easier to track down > and analyse *after* those two known issues will have been eliminated as causes. Why should we have to wait for resolving of these bugs to know about "an Attaching... phenomenon is same as bug 453196/bug 817245 or not", even though "an Attaching... phenomenon is same as bug 453196/bug 817245 or not" is very easily known by checking "Image Location:" and "Order Receved column value" by bug opener himself?

Picking up from https://bugzilla.mozilla.org/show_bug.cgi?id=468159 This bug also occurs when attaching an item to a new message, when the attachment is an attachment to another message (e.g., a message stored in a subfolder of the inbox). There has been no deleting, moving or compacting of messages between the time of composition and attaching the item to the new message, and trying to send the new message. In fact, the new message window displays "attaching [name of image file]" from the moment it is dragged and dropped into the attachment window. For the sake of getting all information in one place, and sorry if this is repetitive, the problem attachment can be opened without any trouble from either it's original location (i.e., the existing message in the folder), or from the attachment window in the new message. In other words, Thunbderbird knows where to find the attachment and can pass it onto the correct handler program w/o any trouble. But, click "send" and the perpetual "Attaching . . . ." window appears. If, instead, I detach the attachment and re-attach it from a file on my hard drive, there is no problem. With respect to comment 22 in https://bugzilla.mozilla.org/show_bug.cgi?id=468159, I do not see how to select "image location" and the attachment isn't an image this time, it's a .pdf. Hovering over the attachment brings up a tool tip containing the following text, all of which looks correct to me (meaning, the path and folder location are correct]: mailbox://C:/Users/[my name]/AppData/Roaming/Thunbdebird/Profiles/[my profile]/Mail/[account]/Inbox.sbd/[subfolder name]/[subfolder name]?number=94667955$part=1.3&filename=[the file name]. I can't find any way to test whether the "number=94667955" part is correct. Happy to keep plugging away at this.

FYI. Main culprit of this kind of problem is "messageKey alteration by Compact". There is no need of "messageKey=messageOffset" in design. If messageKey is not altered by Compact, problem like this bug won't occur, except when (a) user deletes original draft mail while editing draft or forwarding, (b) messageKey is changed by Repair Folder while editing draft or forwarding. Bug 854798 is request of "don't alter messageKey by Compact".

What about not running compact if composition is open? However, that would also need to prevent composition when compact is already started...

(In reply to :aceman from comment #10) > What about not running compact if composition is open? However, that would > also need to prevent composition when compact is already started... Mechanism of this bug is clear. (1) Tb referr to image in other mail(forwarded mail, edited draft) in mail composition window, and the reference is done via messageKey. (2) If IMAP Mbox, messageKey==UID, so messageKey is never altered by Compact. (3) If local mail folder(Berkley Mbox file), messageKey of the referred mail is changed by Compact, because Compact changes offset of mail data in file and current messageKey==messageOffset if Berkley Mbox file. (4) Then composition window can't find referred mail, thus this bug(bug 817245), bug 766495, and bug 799450 occurs. Change in (1) is very difficult, although never impossible(for example, copy image data in referred mail to temporary file). Change in (4) is also difficult, because change in (1) is prerequisite of it. Your proposal is improvement in (3). If such bug happens frequently, prohibit Compact if mail is referred by mail composition window, prohibit forward/edit draft if Compact is already running. This can do nothing on following case; Replied flag is not set, if replied mail's offset is changed after "reply, save as draft" and draft is edited and sent after Compact. To do such thing, a kind of "locking mail" will be needed for resolving this bug and several bugs only. My proposal in Bug 854798 is also an improvement in (3). If messageKey is not altered by Compact, any of bug 817245, bug 766495, and bug 799450 can't occur. So, don't change messageKey by Compact. I think required code change is smaller once "messageKey==highest messageKey+1" will be implemented, because required change for Bug 854798 is "request new messageKey + save the new messageKey in nstmp.msf" => "copy messageKey from original if Compact, except messageOffset(and messageSize if changed)".

We should probably just create a draft snapshot when initializing the composition window, so all the data is stored locally for the new message.

(In reply to Magnus Melin from comment #12) > We should probably just create a draft snapshot when initializing the > composition window, so all the data is stored locally for the new message. +1, I'm 100% in support of that. Wada also indicated something similar as a possible solution in his comment 11 (slightly language-revised by me): > Mechanism of this bug is clear: > (1) In mail composition window, Tb currently uses references to images in > other mail (forwarded mail, edited draft), and the reference is done via > messageKey. > Change in (1) is very difficult, although never impossible (for example, copy > image data in referred mail to temporary file). Something along these lines imho will provide a clean and stable solution to this problem and a host of other problems in multipart compositions: 1) Avoid referencing anything from composition which isn't fully under our control. We can never tell if those things are still there when we eventually try to get them when saving or sending, because referenced messages/files might have been moved or deleted, removable/network media might be gone, local messages offset changed, etc. 2) Instead, whenever something gets attached (file, message, etc.), create a snapshot copy of such data in a TB-controlled temp folder and then reference our own copy which is owned by this composition only (which is what we already do for certain cases, e.g. attaching via MAPI), 3) OR even embed the snapshot data directly/immediately into the composed msg (as we already do for some images copied from elsewhere, and when saving drafts), using data-url, mime parts or such. 4) As an optional exception to that (i.e. as a strictly separate, additional feature with respective UI to be developed), we could allow referencing of external files so that only the most recent version of that file gets included at the time of sending. 5) Currently, we have an awful and practically unpredictable blend of both methods, as I have extensively explained / proven on respective bugs.

(In reply to Thomas D. from comment #13) > (In reply to Magnus Melin from comment #12) > > We should probably just create a draft snapshot when initializing the > > composition window, so all the data is stored locally for the new message. > > +1, I'm 100% in support of that. Wada also indicated something similar as a > possible solution in his comment 11 (slightly language-revised by me): This approach (attach/embed snapshot copies immediately when sending) is also required to solve a lot of UX problems (ux-consistency, ux-error-prevention...) and to enforce the principle of UX-wysiwyg: We need to ensure that what the user actually sees in composition is what will get sent (unless explicitly stated otherwise in the UI). Immediate snapshots are the only way to ensure such parts are still available when saving/sending.

(In reply to Magnus Melin from comment #12) > We should probably just create a draft snapshot when initializing the > composition window, so all the data is stored locally for the new message. "Keep snapshot before start composition" is needed to resolve problem of bug 453196(set in Depends on:), and similar thing is needed for problems pointed in bug 453196 and problem like bug 378046. And, this bug will be apparently resolved by the "Keep snapshot". However, if such change is easy, why bug 453196 which was opened on 2008-09-01 and bug 378046 which was opened on 2007-04-19 are not resolved yet? This bug produces problem of bug 799450 and there is no way to protect Tb user from bug 799450. Who can trust mailer who silently sends confidential data in different mail to unexpected recipients? My proposal is; (1) There is no reason to change messageKey by Compact. Why messageKey is changed by Compact is that messageKey is curretly same as messageOffset which is changed by Compact. (2) If non-mandatory messageKey==messageOffset is removed from Compact, this bug automatically disappears, and bug 799450 also disappears. (3) "Removal of non-mandatory messageKey==messageOffset" is essentially required change in Compact. (4) Therefore, there is no need to do something to resolve this bug and bug 799450 :-)

Well, an initial snapshot would solve bug 799450 too. Even if messageKey isn't changed by compact, you'd still have a problem if the message was moved/deleted when using maildir as there i suppose the files are actually deleted when marked for deletion. I'm not sure how easy it is, but calling save as draft after opening a reply/forward shouldn't be that hard.

Following is interesting test result in Tb 17.0.3 on MS Win. - Initial file size < 4GB - 4MB - 1MB, so POP3 download is initiated - File size before Compact(after POP3 download) / after Compact < 4GB - a 1175 bytes mail of messageKey=4293918873 is deleted before Compact. previous mail is messageKey=4293918872, messageOffset=4293918873, then messageKey is incremented by 1 when downloaded. (1) After POP3 download, Before Compact (file size < 4GB) > 4293918872 = 3 GB + 1023 MB + 0 KB + 152 Bytes > Delta from 4GB = 4GB - 4293918872 = 1023 KB + 872 Bytes < 1024 KB == 1MB (dump data of msgHdr property and StringProperty of storeToken) > mime2DecodedSubject = 1048116B-Mail-000001 : messageKey = 4293918872, messageOffset = 4293918872, messageSize = 1048268, storeToken = same as messageOffset > Deleted => mime2DecodedSubject = 1KB-Mail-000001 : messageKey = 4293918873, messageOffset = 4293918872 + 1048268, messageSize = 1176, storeToken = same as messageOffset > mime2DecodedSubject = 1KB-Mail-000002 : messageKey = 4293918874, messageOffset = 4293918872 + 1048268 + 1176, messageSize = 1176, storeToken = same as messageOffset > mime2DecodedSubject = 1KB-Mail-000003 : messageKey = 4293918875, messageOffset = 4293918872 + 1048268 + 1176*2, messageSize = 1176, storeToken = same as messageOffset (2) After Compact (file size < 4GB) (dump data of msgHdr property and StringProperty of storeToken) > mime2DecodedSubject = 1048116B-Mail-000001 : messageKey = 4293918872, messageOffset = 4293918872, messageSize = 1048268, storeToken = 4293918872 > mime2DecodedSubject = 1KB-Mail-000002 : messageKey = 4293918874, messageOffset = 4294968316, messageSize = 1176, storeToken = 4294968316 > mime2DecodedSubject = 1KB-Mail-000003 : messageKey = 4293918875, messageOffset = 4294969492, messageSize = 1176, storeToken = 4294969492 (i) Mode of messageKey=highest_messageKey+1 looks to start at 4GB-1MB. (ii) When messageKey is highest_messageKey+1 and is greater than threshold(4GB-1MB?), messaeKey is already not altered by Compact. It seems "stop generate MsgKey from offset in Compact" is sufficient.

(In reply to Magnus Melin from comment #16) > Even if messageKey isn't changed by compact, you'd still have a problem > if the message was moved/deleted when using maildir as there i suppose > the files are actually deleted when marked for deletion. I know well it, and the problems you cited are already opened bug 453196, bug 378046 etc. Proposing solution in such bug is better, isn't it? > I'm not sure how easy it is, but calling save as draft after opening a > reply/forward shouldn't be that hard. I guessed "stop generating MsgKey from offset in Compact" is far simpler than such solution you propose, and I believe "stop generating MsgKey from offset in Compact" is right thing. "Resolving problem bug 7994508and this bug)" is merely a fruit of bug 854798.

(In reply to Magnus Melin from comment #16) > Well, an initial snapshot would solve bug 799450 too. Even if messageKey > isn't changed by compact, you'd still have a problem if the message was > moved/deleted when using maildir as there i suppose the files are actually > deleted when marked for deletion. > > I'm not sure how easy it is, but calling save as draft after opening a > reply/forward shouldn't be that hard. +1, but I think it's we need more than just calling save as draft. At least for file attachments, just save as draft without closing and reopening composition will NOT use the saved draft snapshot of the attached file when sending. Try this on a POP3 account: 1) Add foo.txt with content "aaa" as file attachment in composition. Look at attachment filepath in tooltip: -> file://c:/.../foo.txt 2) Save as draft, do NOT close composition. Look at attachment filepath in tooltip: -> still file://c:/.../foo.txt So just "save as draft" is not sufficient. 3) open file://c:/.../foo.txt using text editor, replace "aaa" with "bbb", save it (be fast enough and ensure draft autosave doesn't trigger before next steps) 4) Without closing composition, view source of draft in draft folder -> draft source has mime part foo.txt with "aaa" 5) send message -> sent msg has mime part foo.txt with "bbb" (iirc) Which I think is part of the confusion bug 378046 is trying to solve.

(In reply to WADA from comment #18) > (In reply to Magnus Melin from comment #16) > > Even if messageKey isn't changed by compact, you'd still have a problem > > if the message was moved/deleted when using maildir as there i suppose > > the files are actually deleted when marked for deletion. > > I know well it, and the problems you cited are already opened bug 453196, > bug 378046 etc. Proposing solution in such bug is better, isn't it? Probably yes, but I think it's helpful to realize that full solution to underlying problem of bug 378046 (which essentially calls for the "immediate snapshot copy when attaching") will also solve a host of other bugs including this bug. > > I'm not sure how easy it is, but calling save as draft after opening a > > reply/forward shouldn't be that hard. > > I guessed "stop generating MsgKey from offset in Compact" is far simpler > than such solution you propose, and I believe "stop generating MsgKey from > offset in Compact" is right thing. "Resolving problem bug 7994508and this > bug)" is merely a fruit of bug 854798. I don't fully understand the mechanisms of referencing (parts of) external msgs in composition, but I think WADA is right. WADA: - Is "offset" same as number in "Order received" column which I can add to message list columns using column picker? - What you call "MsgKey": Is it an existing header property of messages (I can't find it!), or is it a term by you for "any unique id of message which can be used for referencing (parts of) that msg"? - If we stop using "offset", what other ID can we use as "MsgKey" in cases of POP (and IMAP)? Or we need to generate a new ID (msgkey) for each POP msg and use that? If yes, can you suggest how to generate unique ID?

(In reply to Thomas D. from comment #20) > > I know well it, and the problems you cited are already opened bug 453196, > > bug 378046 etc. Proposing solution in such bug is better, isn't it? > > but I think it's helpful to realize that full solution to > underlying problem of bug 378046 (which essentially calls for the > "immediate snapshot copy when attaching") will also solve a host of other bugs including this bug. Do you understand why bug 378046 and bug 453196 is placed in "Depends on:" field of this bug? It's already aparent, isn't it? Why "repeated stating about it in this bug" is needed? > - What you call "MsgKey": Is it an existing header property of messages It's shorthand of, or string frequently used for variable name for, nsIMsgDBHdr.messageKey. (if accessed via XPCOM, nsIMsgDBHdr is shown as [xpconnect wrapped nsIMsgDBHdr]). See dump data of nsIMsgDBHdr in comment #17. > - Is "offset" same as number in "Order received" column which I can add to message list columns using column picker? "offset" is frequently shorthand of nsiMsgDBHdr.messageOffset of Berkley Mox file. Value shown in "Order Received" column is nsiMsgDBHdr.messageKey. If IMAP, UID is used for messageKey value. If Berkley Mbox file, messageOffset value is currently used for messageKey value except when offset>4GB-1MB(read comment #17). What value is used for messageKey value in maildir is different from others. "Identifier used to point previous draft for image location" is messageKey value, and messageKey is currently same as messageOffset in Berkley Mbox file, so I callled it "Offset".

(In reply to WADA from comment #21) > (In reply to Thomas D. from comment #20) > > - What you call "MsgKey": Is it an existing header property of messages This msg key only exists in the msf file not in the mbox data file so you will not find it. It is generated when a message comes in and is a unique identifier inside a folder to reference a message internally in TB. With the key, the database (msf) finds the proper offset to retrieve the message data from the mbox file. Most of the time the key value equals offset value but it is not strictly necessary and those are strictly separate concepts.

Thanks WADA & aceman for explaining. To push this bug forward, I'd like to clarify WADA's proposed solution: If we stop using "msgKey==msgOffset" for Berkeley Mbox files, what other ID can we use as "MsgKey" in such cases? Can you explain/suggest where to get / how to generate unique ID for "msgKey==ID"?

(In reply to Thomas D. from comment #19) "Start from 1, incremented by 1, whch is generated by MorkDB", as done in Maildir by Tb and in UID of IMAP by server, and "re-assign from 1 incremneted by 1, only by Repair Folder" as done in Maildir. Why don't you read bug 854798? As you know, bug 453196 can't be resolved by change for bug 854798, and similar solutition to bug 453196, "Keep snapshot", is mandatory for bug 378046. bug 453196 : (a) snapshot of forwarded mail. this bug : (b) snapshot of edited draft mail. bug 378046 : (c) snapshot of attaching file via MAPI, via drag etc. and (d) option of (d-1) "use snapshot by Send or Save", (d-2) "use recent file data by Send or Save", is needed. (a)/(b)/(c) is required feature before start of mail composition and common requirement, but (d) is feature in "end of mail composition" which is needed for bug 378046 only, because (d) is always (d-1) in bug 453196 and this bug. So, (a)/(b)/(c) can be implemented in any bug, but (d-2) can be implemented by bug 378046 only. I recommend you to open independent/common bug for enhancement of "keep snapshot before start compositon" for (a)/(b)/(c) with always (d-1), and to implement (d-2) in bug 378046 for specific requirement in that bug. By the way, thanks for touching up Whiteboard. If you can, touch up my already posted comments ... ;-)

(In reply to WADA from comment #24) > (In reply to Thomas D. from comment #19) > "Start from 1, incremented by 1, whch is generated by MorkDB", as done in > Maildir by Tb and in UID of IMAP by server, and "re-assign from 1 > incremneted by 1, only by Repair Folder" as done in Maildir. Why don't you > read bug 854798? Sorry, that one hadn't been on my radar yet. It's also no easy reading ;) > As you know, bug 453196 can't be resolved by change for bug 854798, and > similar solutition to bug 453196, "Keep snapshot", is mandatory for bug > 378046. Yes. > bug 453196 : (a) snapshot of forwarded mail. > this bug : (b) snapshot of edited draft mail. > bug 378046 : (c) snapshot of attaching file via MAPI, via drag etc. Generally right: bug 378046 advocates for "immediate snapshot when attaching" as default behaviour for file attachments regardless of the method of attaching. But above description of bug 378046 is prone to misunderstandings, better rephrased: bug 378046 : (c) need immediate snapshot of file attached via NON-MAPI methods (attaching from inside TB or via drag & drop), for consistency with MAPI methods (Explorer > Send to > Email-Recipient), where we already take immediate snapshot. > and (d) option of (d-1) "use snapshot by Send or Save", > (d-2) "use recent file data by Send or Save", is needed. Rephrase: Yes, for the scenarios "save as draft" and "send", ideally there should be a *choice* between (d-1) "use snapshot originally taken when file was attached" (aka attach immediately) - that's proposed solution for bug 378046 (possible now) (d-2) "get snapshot of most recent file data only just before sending" (aka attach later when sending) - that's new feature of Bug 722929 (where UI and behaviour need yet to be specified, e.g. taking fallback interim snapshots etc.) > (a)/(b)/(c) is required feature before start of mail composition and common > requirement, but (d) is feature in "end of mail composition" which is needed > for bug 378046 only, because (d) is always (d-1) in bug 453196 and this bug. > So, (a)/(b)/(c) can be implemented in any bug, but (d-2) can be implemented > by bug 378046 only. > I recommend you to open independent/common bug for enhancement of "keep > snapshot before start compositon" for (a)/(b)/(c) with always (d-1), and to > implement (d-2) in bug 378046 for specific requirement in that bug. Yes, we need a new bug for "take immediate snapshot copies of all things attached" (before or during composition). I have long realized the need for such bug as a way of outsourcing the required solution to bug 378046, but with that bug's long history of misconceptions by others about current and needed default behaviour, I never got round to that. I think the new bug needs to be phrased very carefully with clear references to all the bugs this will solve (and how), to avoid getting more of that nonsense which tried to invade bug 378046. > By the way, thanks for touching up Whiteboard. If you can, touch up my > already posted comments ... ;-) I sometimes catch myself wishing I could, but I'm afraid I can't... luckily for the two of us ;) But we might try that again after Bug 540 ;-) Notwithstanding the language limitations, I always appreciate WADA's extraordinary code knowledge, crisp analysis skills and wide awareness of existing bugs including their connections and delimitations (which he's guarding with that extra inch of strictness, for our own good...). Thanks for that! :)

(In reply to WADA from comment #24) > By the way, thanks for touching up Whiteboard. If you can, touch up my > already posted comments ... ;-) ...and I'll also gladly ask WADA to touch up some of mine ;-)

+1 for this bug report. Still affected by it.

(In reply to martin.monperrus from comment #29) > +1 for this bug report. Still affected by it. What is your TB version?

My version is 31.6.0

We only did something for this problem in bug 854798 and the change is in TB38. So please test that one, as reports against older versions will not be useful. Thanks. We now wait for reports to determine if bug 854798 also really fixed this one. See comments starting from comment 9.

Still affected by this bug with version TB38 (beta channel).

Martin, can you confirm you really see that the message keys are being changed by the compact? You can see the message keys by enabling the "Order received" column in the affected folder.

I only confirm that the symptom "Tb spins with "Attaching...", when the original mail is HTML mail with embed image." sill appears in TB38. This bug is clearly not deterministic (sometimes it happens, sometimes not). Maybe related to the draft saved by auto-save which is enabled in my case (bug 591181).

Because bug 854798 was fixed and patch for that bug was already shipped as official Tb 38 release and current official Tb release is already Tb 40, this bug won't occur merely by "Compact while composing Reply/Forward mail" anymore. To force this bug, "Delete mails + Compact + Repair Folder" is needed to force this bug. "Repair Folder" can occur only when: (A) User intentionally does do manual Repair Folder of relevant message folder (B) Automatic internal Rebuild-Index happened on relevant message folder(call FolderX. if draft editing, it's Drafts). I believe (A) usually won't occur in ordinal environment and (B) is pretty rare special edge case in special environment. This bug won't occur merely by Compact anymore in usual environment of ordinal Tb users. Closing as Fixed. If closing is wrong, please reopen with sufficient data for problem anlysis and detailed description of phenomenon.

If you see phenomenon of this bug in Tb 38 or newer, see and read bug 1201782, please.

Still affected by this bug (cannot answer to message with embedded image) in EarlyBird 47.0a2 (2016-03-24).

(In reply to monperrus from comment #38) > Still affected by this bug (cannot answer to message with embedded image) in > EarlyBird 47.0a2 (2016-03-24). If you still see this problem and have repaired the folder when using a current version, please file a new bug report