1201782 - Phenomenon of bug 766495 (wrong image), bug 799450 (text data for image), and bug 817245 (endless attaching) ... even when Compact doesn't change messageKey. Caused by Repair Folder making messageKey re-used in MessageCopyMove and changed messageKey

Status: RESOLVED FIXED

(MailNews Core :: Composition, defect)

Description

[WADA:World Anti-bad-Duping Agency]

+++ This bug was initially created as a clone of Bug #799450 +++

Phenomeno of bug 799450(image of other mail is used), bug 766495(confidential text data in other mail is silently sent as image data), bug 817245(endless Attaching...), can occur, even when Compact doesn't change messageKey after fix of bug 854798, because messageKey can be re-used by MessageCopyMove and messageKey is changed by Repair Folder.


(a) Interfere by Mail Copy/Move to relevant folder : bug 799450, bug 766495 can occur
>     In STR of Bug 799450 Comment #10 :
>     after Compact, in Tb 38.2.0, mail at Offset=4000 is changed to messageKey=4000, messageOffset=0.
>     At this step, this bug is resolved, because messageKey is not chaged by Compact.
>     Hoewever, if no other mail is held in in this folder,
>     and if other mail is copied to folder after Compact before Draft save at composer,
>     copied mail has messageKey=4000, messageOffset=4000.
>     By this copied mail, referred mail of messageKey=4000, messageOffset=0 is hidden,
>     and the copied mail of messageKey=4000, messageOffset=4000 is used upon next draft save at composer.
>     If the copied mail of messageKey=4000/messageOffset=4000 has similar mail data structure,
>     same phenomenon as this bug can happen.
>     This is a dataloss issue in bug 1183490.

(b) Interfere by Repair Folder : bug 799450, bug 766495 can occur
>     In STR of Bug 799450 Comment #10 :
>     after Compact, in Tb 38.2.0, mail at Offset=4000 is changed to messageKey=4000, messageOffset=0.
>     At this step, this bug is resolved, because messageKey is not changed by Compact.
>     However, if Repair Folder of relevant folder is executed after Compact before Draft save at composer,
>     phenomenon of this bug can occur, because referred maii is changed to messageKey=0, messageOffset=0,
>     and other mail held at offset=4000 becomes mail of messageKey=4000, messageOffset=4000.
 
(c) Interfere by Repair Folder : bug 817245 can occur
>     In STR of Bug 799450 Comment #10 :
>     after Compact, in Tb 38.2.0, mail at Offset=4000 is changed to messageKey=4000, messageOffset=0.
>     At this step, this bug is resolved, because messageKey is not changed by Compact.
>     However, if Repair Folder of relevant folder is executed after Compact before Draft save at composer,
>     and if mail of messageKey=4000(mail held at Offset=4000) doesn't exist,
>     bug 817245 occurs.

Comment 1

[WADA:World Anti-bad-Duping Agency]

In case (c), if mail of msgOffset=4000 is text/plain after Compact+Repair Folder, endless Attaching... occurs.

Because "any other code than Compact arround messageKey assignment" is not changed, any relevant bugs can pretty easily be reroduced by "Compact + Repair Folder" while mail composing.
  "Compact + Repair Folder after fix of bug 817245" is absolutely same as "Compact before fix of bug 817245"

Comment 2

[Thomas D. (:thomas8)]

rkent (fyi), this conglomerate of symptoms where we randomly and silently expose unrelated private data in composed messages is a massive violation of user privacy. It's a general design bug whose causes can probably be narrowed down to one or two key issues, following WADA's in-depth analysis. I'm not sure how often this occurs, but imho, as a matter of principle this deserves developer attention pretty soon.

Comment 3

[:aceman]

Somehow I do not understand this bug. In what cases can message key get reused?

Comment 4

[WADA:World Anti-bad-Duping Agency]

(In reply to :aceman from comment #3)
> Somehow I do not understand this bug. In what cases can message key get reused?

Test mails attached to bug 799450 comment #10 :
4 mails :
  mail-00-A : 4000 bytes text/plain mail   (offset=0)
  mail-01   : 4000 bytes multipart/related (offset=4000)
                part1.1 : text/html, img src="cid:png-A", img src="cid:png-B"
                part1.2 : image/png, Content-ID: <png-A> (green)
                part1.3 : image/png, Content-ID: <png-B> (magenta)
  mail-02   : 4000 bytes multipart/mixed   (offset=8000)
                part1.1 : text/plain
                part1.2 : image/png (red)
                part1.3 : text/plain, filename="attached...TXT"
  mail-00-B : 4000 bytes text/plain mail   (offset=12000)

[Steps to reproduce "Re-use of messageKey by Message Copy"]
(1) Save the attached file as "Drafts" file and "Test" file of POP3 account or Local Folders.
    Edit "Drafts" file, change "Subject: mail" to "Subject: #ail" for eye catcher.
    (keep newline=CRLF, don't change length of each mail)
    Restart Tb, "Repair Folder" of Drafts folder and Test folder, Show "Order Received" column.
(2) Edit draft #ail-01 (Offser=4000, so messageKey=4000)
    current draft : messageKey=4000, so data in this draft is pointed by key=4000.
(3) Delete #ail-00-A(offset=0), #ail-02(offset=8000), #ail-00-B(offset=12000), Compact
    => #ail-01 is shifted to Offset=0 (messageKey=4000, messageOffset=9, fileSize=4000)
(4) Copy all 4 mails in Test folder to Drafts folder.
    => mail-00-A has messageKey=4000, messageOffset=4000.
    => #ail-01(messageKey=4000, messageOffset=0) disappers from Thread pane.
       => #ail-01 is replaced by mail-00-A
(5) At composition window, Save as draft,
    => Because mail-00-A(messageKey=4000) is text/plain mail, endless Attaching... occurs.
(6) At Drafts folder, Repair Folder
    => Following mails are shown
       #ail-01(messageKey=0, messageOffset=0)
       mail-00-A(messageKey=4000, messageOffset=4000)
       Other mails follows.
If mail-02 is mail of messageKey=4000, messageOffset=4000 after "Compact + Copy",
Image of other mail, other mail's text for image data, can be observed at step (5).

Phenomeno is:
  When mailX of messageKey=XXX/messageOffset=XXX is changed to
     messageKey=XXX/messageOffset=YYY where YYY<XXX by Compact,
  if a mailZ is unfortunately added to Offset=XXX,
     mailZ has messageKey=XXX/messageOffset=XXX,
  so mailX(offset=YYY<XXX) is replaced by mailZ(offset=XXX) in msgDB,
  then mailX is removed from Thread pane.

Comment 5

[Kent James (:rkent)]

(In reply to Thomas D. from comment #2)
> rkent (fyi), this conglomerate of symptoms where we randomly and silently
> expose unrelated private data in composed messages is a massive violation of
> user privacy. It's a general design bug whose causes can probably be
> narrowed down to one or two key issues, following WADA's in-depth analysis.
> I'm not sure how often this occurs, but imho, as a matter of principle this
> deserves developer attention pretty soon.

I know what you would like me to say is, "Oh yes I'll drop everything and get right on this!" but the reality is that I already have many other such bugs asking for my attention, and in the meantime I an unfairly ignoring my own customers. Plus the massive changes to the core Mozilla code threaten the viability of by main effort, ExQuilla and need urgent attention.

The reality is that the plan to deal with such critical issues involves the reorganization of Thunderbird to provide some resources to able to address issues, and I am the critical path for that at the moment.

So my "need info" response is that yes this is an issue, and the solution is for me to focus less on fixing bugs, and more on the longer-term viability and funding issues.

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to Thomas D. from comment #2)
> I'm not sure how often this occurs, (snip)

Probability of relevant problems occurs =
   (a) Probability of "composing mail involves embed image in HTML"
 * (b) Probability of "cid: URL of embed image points other mail of messageKey=XXX"
 * (c) Probability of "messageKey=XXX of the pointed mail is changed during composing"
(a) and (b) is same in "before fix of bug 832519" and "after fix of bug 832519".
(C) =
  before fix of bug 832519 :
     (d) Probability of "Compact is invoked during composing"
   * (e) Probability of "Offset of the pointed mail is changed by the Compact"  
  after fix of bug 832519 :
     (d) Probability of "Compact is invoked during composing"
   * (e) Probability of "Offset of the pointed mail is changed by the Compact"  
   * (f){
           (g) Probability of "Repair Folder is invoked after the Compact during composing"  
         + (h) Probability of "a mail is copied to Offset=XXX after the Compact during composing" 
        }    

I believe (f) is small, so I believe "frequency of problems happens" is minimized by fix of bug 832519.

And, even if one of bug 766495, bug 799450, bug 817245 can occur, critical issue is problem of bug 799450 only.
When above conditions are met,
  1 =
       (i) Probability of "mail of messageKey=XXX(messageOffset=XXX) is NOT generated"
     + (j) Probability of "mail of messageKey=XXX(messageOffset=XXX) is generated"
  And, (i) >> (j)
If (i), problem occurs = bug 817245 only. Because of (i) >> (j), majority is bug 817245. 
IIRC, error dialog is shown in this case. 
If (j), which problem occurs is ;
  (j-1) if mail of messageKey=XXX(messageOffset=XXX) == text, bug 817245
  (j-2) if mail of messageKey=XXX(messageOffset=XXX) == multipart,
     (j-2-1) if the multipart mail does not have corresponding subpart, bug 817245
     (j-2-2) if the multipart mail has corresponding subpart(Part.p.q.r),
        (j-2-2-1) if the corresponding subpart == image, bug 766495
        (j-2-2-2) if the corresponding subpart == text,  bug 799450
        (j-2-2-3) if the corresponding subpart == other, bug 799450

Reason why Severity=Critical of this bud is "problem of bug 799450 is involved".
But Probability of bug 799450 is pretty low, although it's not negligible.

Comment 7

[:aceman]

(In reply to WADA from comment #6)
>    * (e) Probability of "Offset of the pointed mail is changed by the
> Compact"  
>   after fix of bug 832519 :
>      (d) Probability of "Compact is invoked during composing"
>    * (e) Probability of "Offset of the pointed mail is changed by the
> Compact"  
>          + (h) Probability of "a mail is copied to Offset=XXX after the
> Compact during composing" 

So you still think the compose code "pins" the attachment data via the offset and not via the key? And the offset of the data is changed after compact.

Comment 8

[:aceman]

I mean not that you think that is how it should work, but that there is still some place in the code that thinks key=offset or just directly uses offset and that is the bug here?

Comment 9

[WADA:World Anti-bad-Duping Agency]

(In reply to :aceman from comment #8)

Composer code, or mailbox: URL processor, uses pointer to mail as messageKey, as expected.
  mailbox:.../Inbox%3Ennn?part=1.2&filename=EmbedImage.jpg
  nnn is interpreted as messageKeu=nnn,
  so "messageKey=nnn / messgeOffset!=nnn after Compact" is normally accessed,
  and if messageKey=nnn is overlaid by other mail of messageKey=nnn/messgeOffset=nnn, it's accessed.

> I mean not that you think that is how it should work, but that there is still some place in the code
> that thinks key=offset or just directly uses offset and that is the bug here?

I don't know. I know only that at least CopyMove and Rebuild-Index assigns messageOffset value to messageKey.
I don't think that someone uses key as Offset in phenomenon/problem of this bug.

Comment 10

[WADA:World Anti-bad-Duping Agency]

Even if following will be implemented,
  (A) CopyMove assigns messageKey = Highest key in msgDB + 1
  (B) "Repair Folder" starts from messageKey=1 with incrementing by 1
as far as function like "Repair Folder", or "Reorganize Folder == re-assign messageKey from 1 in case of messageKey overflow", changes messageKey value of existent mail,
and as far as composer code uses messageKey for pointing referred message and its data,
problem of this bug can surely occur by "Compact + Repair Folder while mail composing".
By (A)/(B), "probability of problems in this bug happens" declines more, but it's still greater than ZERO, and I believe it's not negligible.
To resolve problem like this bug, essential change in composer, for example, "Copy mail data when mail is referred", is needed. "Prohibit Compact/Repair Folder of relevant Folder while Composer is running" is an alternative for solution of this bug.

Comment 11

[WADA:World Anti-bad-Duping Agency]

Probability of problem is perhaps slightly higher my previous estimation.

After fix of bug 832519, when Compact is executed at a folder, at least several mails have messageKey=XXX/messageOffset=xxx where XXX is larger than fileSize after Compact and xxx is smaller than fileSize after Compact.
Because auto-compact=on is set by default, and because mail add/mail delete is done pretty frequently by auto-save which is also on by default, probability of "draft mail has messageKey=XXX/messageOffset=xxx(XXX>fileSize&&xxx<fileSize)" is high. 
So, draft edit is frequently invoked for messageKey=XXX/messageOffset=xxx(XXX>fileSize&&xxx<fileSize).
If mail addition occurs on this folder during editing draft, there is a chance of "mail of messageKey=XXX/messageOffset=XXX is generated and mail of messageKey=XXX/messageOffset=xxx is overlaid".
When Drafts, "mail addition" is usually done by "save of new version of draft".
So, if user edits multiple draft mails concurrently, "draft save at a draft editing" can generate draft mail of messageKey=XXX/messageOffset=xxx(XXX>fileSize&&xxx<fileSize) where XXX is other draft's messageKey.
If draft mail, user usually is not aware of "loss of old version of draft at Thread pane", so "ovwrlay of messaageKey by CopyMove" is not exposed.

Similar phenomenon to bug 766495 in Tb 38 and similar phenomenon to bug 817245 in Tb 38 was reported to Bug 1180201.
It may be above case, because I can't imagine "Compact + Repair Folder while composing" nor "Repair Folder while composing" nor "mail copy to Drafts while composing", and because reporter says "first one in Drafts was OK but second one in Drafts had problem".

Comment 12

[WADA:World Anti-bad-Duping Agency]

FYI. I've opened bug 1202105 for phenomeno of comment #4.

Comment 13

[WADA:World Anti-bad-Duping Agency]

I wanted to say...
　 "Probability of that problem occurs" is perhaps slightly higher than my previous estimation.

Comment 14

[Temp]

I'm not sure, if I'm writing in appropriate bug-thread (found too many possibly matching).
In my Thunderbird 38.3.0 image in cited signature was replaced between two auto-saves of draft (5 minutes). Very bad luck, that it was replaced with logo from mail to/from competing company and I didn't notice it before sending mail (but who would?).

In account's draft folder (local, not IMAP) I have 1 draft with correct image, and another one, created exactly 5 minutes later - with wrong image, that was sent. I didn't compact nor repair any folders in that period (or even day, week and probably month).

Having multiple (auto created) drafts of the same message (as it was being composed) is probably also some kind of a bug, but not so annoying and privacy compromising.

Comment 15

[WADA:World Anti-bad-Duping Agency]

(In reply to Temp from comment #14)
> I'm not sure, if I'm writing in appropriate bug-thread (found too many possibly matching).

This bug is perhaps for your problem.
Read bug 766495(wrong image) and and bug 799450(text data for image) well for detail of phenomenon, please.

> Having multiple (auto created) drafts of the same message (as it was being composed)
> is probably also some kind of a bug, but not so annoying and privacy compromising.

In Tb 38 or newer(nightly), Bug 1183490 can occur in such case. "Draft Save" is identical to "mail copy to Drafts" from perspective of messageKey. So Bug 1183490 can produce phenomenon of this bug, in addition to "Repair Folder after Compact!, as written in bug summaary.

If you have IMAP account, using IMAP folder as Drafts is a warokaround of this bug if you freuently experience problem of this bug, only when your IMAP server is stabilized.
"Dummy POP3 account(with non-existent server) with MaildirStore" and "Drafts of the dummy POP3/MailDir account" may be a workaround of this bug, if Drafts folder is relevant.
(Note: MailDir is still experimetal feature.)

Comment 16

[Miloš Havlíček]

We have exactly the same problem as described in the first post of Bug 532395 still in the Thunderbird v. 38.3.0 on Windows 7 Ultimate x64!

Comment 17

[baptx]

I have experienced this crazy bug today. I found a bug report https://bugzilla.mozilla.org/show_bug.cgi?id=807319 which redirected me to https://bugzilla.mozilla.org/show_bug.cgi?id=766495 which redirected me to this one.
I am looking for a job and replied to a recruiter by attaching a doc file. The person used a signature with an image and I didn't noticed any change before clicking the send button.
After sending the message, I looked at my "Sent Mail" folder and saw that his company logo has been replaced by another company one, which contacted me a few weeks ago.
This is a serious privacy problem (and dataloss like this bug report says), it could have sent anything confidential or compromising.
I have used Thunderbird 38.2.0 on Xubuntu 14.04 LTS. I am using a Gmail email address and the Thunderbird Enigmail addon (for PGP signature most of the time).
When I have sent the message, I have noticed that my system asked me twice for my PGP password. I found that the message was both in my local draft folder (but I don't remember saving it as a draft before sending) and in my "Sent Mail" folder.
To be sure that a wrong image was really sent to the recipient, I connected to Gmail web version and saw the wrong image.
I couldn't reproduce the bug a second time by attaching the same file and writing the same message to send it to my own email address.
Is the problem really due to compacting messages? I have noticed Thunderbird ask me sometimes to compact folders so I answer yes.
What can we do to prevent the problem until the bug is fixed?

Comment 18

[monperrus]

Happens today with TB 43.0a2 (earlybird)

Comment 19

[Pim Blokland]

(In reply to baptx from comment #17)
> What can we do to prevent the problem until the bug is fixed?

If the problem only occurs during compacting, switch off automatic compacting. Then only compact manually, at those times when you're not writing (and/or have saved as draft) any emails.

Comment 20

[monperrus]

> switch off automatic compacting

Do you mean option "Preferences >> Advanced >> Network & Disk Space >> compact all folders when it will save over X Mb in total"?

Comment 21

[Matt]

(In reply to martin.monperrus from comment #20)
> > switch off automatic compacting
> 
> Do you mean option "Preferences >> Advanced >> Network & Disk Space >>
> compact all folders when it will save over X Mb in total"?

That would be it.

Comment 22

[monperrus]

> If the problem only occurs during compacting, switch off automatic compacting.

The problem occurs even when automatic compacting is switched off.

Comment 23

[Gulamilue]

Hello, I have also a problem with wrong image sent in the message's body.
Like people, the problem is still happenning with version 38.5.1 or Earlybird, and Compacting folder swithed off or on. 

My inbox is large, and I usually use picture in the body with Copy Ctrl+C and Paste Ctrl+V.
Before it was sometimes and take always the same wrong image. After moving to Archives and compacting folders, the problem is often. The wrong image was changed. 
Thunderbird takes pict from another old mail like a lotery.

It seems to happen easier when "reply to"   or   "edit as new message"   or   when taking a pict Ctrl+C and Paste Ctrl+V from another message.
Sometimes when saving to draft, the dialog box is locked with description "attaching image".
(In a previous version, some messages were saved in Drafts many times)

So, it may be also a problem with save to Drafts.
In Options / Composition / General , I switch off "Auto Save every" 5 min
The problem do not reproduce for the moment.
But if there is a problem with a picture, when sending message, a message box is "Sending of the message failed"

Comment 24

[WADA:World Anti-bad-Duping Agency]

As I wrote in Bug 1144020 Comment #4, "Re-use of messageKey of already deleted mail" can occur only after "Delete mail(s) + Compact + Repair Folder"(from Tb 45).
"Re-use of messageKey of already deleted mail" won't occur by "Delete mail(s) + Compact"(after Tb 38)
and it won't occur by "Delete mail(s) + Compact + Copy/Move"(after Tb 45).

So, problem occurs only when:
  Composer refers messageKey=A as current draft mail/forwarded mail/replied mail.
  While composing, deletion of mail of mwssageKey<A happens, and compact is execuyed, and Repair Folder is executed.
  => By Delete/Compact/Repair Folder, messageKey=A can be assigned to other mail after Repair Folder.
I can't think that "Repair Folder of a relevant mail folder to mail composition while relevant mail is being composed" occurs frequently in normal/ordinal environment.

Comment 25

[Bo Weidema]

I cannot agree that this does not occur "frequently in normal/ordinal environment". I have a colleague next to me for whom it happened a year ago, and it just happened to me (sending an irrelevant image to a customer in place of his own logo...).

Comment 28

[Matt]

Just wanted to mention that this happens to me almost every single day.
If I catch it before I hit send, I can remove the other randomly inserted messages, but more than once I've noticed it after the fact. 

It has the potential to be really embarrassing.

Comment 29

[baptx]

Something even worse for privacy happened to me some times ago. Like I previously reported, Thunderbird sent a previously contacted recruiting company logo to another recruiting company but I also discovered that it sent a complete email conversation with a recruiting company to another recruiting company, inside the company image signature, encoded as Base64. It was possible to decode the content manually when viewing email source in Thunderbird or when connecting to Gmail web version, a simple right click -> "View image" on the blank image signature downloads the complete conversation as an HTML file.
This is scary and means Thunderbird can be a really dangerous software for your privacy, even if open source. Since then, I disabled HTML emails and write only text emails. In your account settings, go to "Composition & Addressing" and uncheck "Compose messages in HTML format". If you really want to write HTML emails on some occasions, you can press "shift" key while pressing the "Write" button to create a new email.

Comment 31

[Jason]

This happened to me in version 45.4.0.  I have never noticed this problem previously.  It is very disconcerting since I am exchanging sensitive communication with a security firm!

Comment 32

[Jorg K (CEST = GMT+2)]

(In reply to Matt from comment #28)
> Just wanted to mention that this happens to me almost every single day.
Can you reproduce it reliably?

(In reply to Jason from comment #31)
> This happened to me in version 45.4.0.

Switch off auto-compact.
Clean out old drafts from your Drafts folder. Repair. Compact. Repair again.

At the end of the day when all the messages are sent, the Drafts folder should be empty.
Compact and repair it from time to time.

If it's very important, send the message "later", inspect it in the Outbox before shipping it out.

Comment 33

[Matt]

(In reply to Jorg K (GMT+2) from comment #32)
> (In reply to Matt from comment #28)
> > Just wanted to mention that this happens to me almost every single day.
> Can you reproduce it reliably?

I don't know the exact set of events that triggers it, but it happens a lot. Lately, it pops up when I try to forward a message. Instead of the message I'm forwarding, I frequently get something from my drafts instead. That's frustrating because it's not that there is extra text that I can delete, it's a totally different message! In these cases I often have to try 2-3 times or restart Thunderbird.

I've had auto-compacting turned off for a while (in effort to avoid this), but I didn't know about keeping the drafts folder emptied, repaired, and compacted. I'll try to do those things to help out until this can bug can be squished.


> (In reply to Jason from comment #31)
> > This happened to me in version 45.4.0.
> 
> Switch off auto-compact.
> Clean out old drafts from your Drafts folder. Repair. Compact. Repair again.
> 
> At the end of the day when all the messages are sent, the Drafts folder
> should be empty.
> Compact and repair it from time to time.
> 
> If it's very important, send the message "later", inspect it in the Outbox
> before shipping it out.

Comment 34

[Matt]

(In reply to Matt from comment #33)
> (In reply to Jorg K (GMT+2) from comment #32)
> > (In reply to Matt from comment #28)
> > > Just wanted to mention that this happens to me almost every single day.
> > Can you reproduce it reliably?
> 
> I don't know the exact set of events that triggers it, but it happens a lot.
> Lately, it pops up when I try to forward a message. Instead of the message
> I'm forwarding, I frequently get something from my drafts instead. That's
> frustrating because it's not that there is extra text that I can delete,
> it's a totally different message! In these cases I often have to try 2-3
> times or restart Thunderbird.
> 
> I've had auto-compacting turned off for a while (in effort to avoid this),
> but I didn't know about keeping the drafts folder emptied, repaired, and
> compacted. I'll try to do those things to help out until this can bug can be
> squished.

Follow up here. I still see this bug even with all the mitigations mentioned.

Today I sent a message. Later I composed a new message (not a reply or forward), and the last message was in my new message. I cleared that out and sent my 2nd message. Now the 2nd message appears when I compose a new message.

I then tried repairing and compacting my inbox, sent, and drafts folders (although drafts was empty).
Composing a new message contained the 2nd message again.

Comment 35

[Charles]

This does not sound like what this bug is about.

It also sounds like you have some other problem going on. I have never seen this in all my days of using TBird.

Have you tried in Safe Mode?

Comment 36

[Matt]

(In reply to Charles from comment #35)
> This does not sound like what this bug is about.
> 
> It also sounds like you have some other problem going on. I have never seen
> this in all my days of using TBird.
> 
> Have you tried in Safe Mode?

I can try running with that for a few days.

I originally got here because of Bug 799450, the title of which includes: "Thunderbird adds the text of an email in the Drafts folder to an email I send" -- This is what I was seeing. Now I'm seeing it with sent mail, in the same way. That's a very strange coincidence, but I certainly could be wrong about it being the same thing.

The reason I'm watching this bug and hoping for a fix is that the title of this bug that says 799450 and a few others can still happen. As a side note, it also has the text "text data for image" for 799450 which kind of buries what that bug is/was about.

Comment 37

[Matt]

(In reply to Matt from comment #36)
> (In reply to Charles from comment #35)
> > This does not sound like what this bug is about.
> > 
> > It also sounds like you have some other problem going on. I have never seen
> > this in all my days of using TBird.
> > 
> > Have you tried in Safe Mode?
> 
> I can try running with that for a few days.

Safe Mode worked. I have identified a an Add On that was the culprit. 

Add On developer suggested this work around, which seems to also work with the Add On enabled:

mail.compose.max_recycled_windows=0

Sorry for another post on this, but I wanted to give kudos for the suggestion (I didn't even realize I had any add-ons in TBird or that there was safe mode), admit that I was wrong about experiencing this bug and provide the info about how to fix my issues in case the fix helps developers with any related bugs.

Comment 38

[Jorg K (CEST = GMT+2)]

Window recycling was removed from Thunderbird at version 48. Try the current TB 50 beta.

Comment 39

[WADA:World Anti-bad-Duping Agency]

(In reply to Jorg K (GMT+2) from comment #38)
> Window recycling was removed from Thunderbird at version 48. Try the current TB 50 beta.

There is no need to use beta or nightly merely for disabling "composer window recycling" for test purpose.
By mail.compose.max_recycled_windows=0, composer window recycling is not used.

Comment 40

[Leszek Dubiel]

I have set mail.compose.max_recycled_windows=0  and it DIDN'T help. 
This terrible error still exists and images are sent randomly to unwanted recipients. 
Our workers and directors tell me to move to another program, because "you Thunderbird" would some day cause us lots of trouble if information leaks.

Comment 41

[Jorg K (CEST = GMT+2)]

Use TB 52 beta from (https://www.mozilla.org/en-US/thunderbird/channel/) coming out as the new TB 52 ESR in March.
I'll shout you a beer if you can reproduce the bug in that version!

Comment 42

[Jorg K (CEST = GMT+2)]

Let me add: With that version the image you see in your composition will be 100% what you will send. There is absolutely zero chance that something else will ever be sent.

Technical background:

Previously, pictures in the compose window were loaded as references to other message parts. Sometimes the parts changed and something wrong got sent.

We have completely reworked the compose pipeline and the way pictures are embedded into the composition: Their data is now directly included in the compose window and not pulled in from a reference. Hence the system is now 100% WYSIWYG.

Comment 43

[ilardone]

I agree with Leszek Dubiel, I have the same petition from my director. I really do not want to change TB, all workers are used to TB, they like it and use it fully. But this image problems keeps appearing, and directors want to kill me ! I hope in versión 52 this problem is solved.

Comment 44

[Jorg K (CEST = GMT+2)]

Oh, and while I'm here, let's close this bug.

As per comment #42: Fixed in TB 52 be reworking image inclusion.