User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Build Identifier: version 0.9 (20041103) You can put an image into a mail with Paste. If you save this mail as a draft, everything is fine, and you can open it again and the images is still there. But if you save twice in a row, the image disappears from the mail (the next time you open the mail) This is a bug that goes all the way back to at least Netscape 4.x But in Netscape it was more tricky: if you made a change to the mail and saved it, and then made more changes and saved a second time, then the image was lost. In Thunderbird you don't have to make any changes, just saving it twice will cause the image to disappear. To remedy the problem, you can save only once, close down the mail window and open it again to make more chances and then save only once again. In Netscape you could specify that the image should be "left at the original location". Then it worked fine. But as soon as you switched this of, you would get an error message after making changes, saving, making changes and saving a second time. It would be REALLY nice to be able to select "Leave image at original location" in Thunderbird, as you could in Netscape. Otherwise it is a lot of work (and failures) to be editing a newletter and saving at regular intervals. During editing you should be able to leave at original location and then you could switch this off before the mail was finally sent. Reproducible: Always Steps to Reproduce: 1. Start a new mail 2. paste an image into it 3. Save 4. Save a second time 5. Close the window of the mail you have been editing 6. Open the specifik mail again Actual Results: Images disappear Expected Results: Saves the images to a temporary location (it does, but cannot find the location after two saves and edits in a row)

I see this with TB 0.9+1112, Win2K. It seems to be pretty reproducible. It's not limited to pasted images; same response for those included via Insert|Image. The <img> tag is still in the message, and refers to a cid: part; that part's headers are in the message, but the data is missing. I see a closely related symptom with Moz 1.8a5-1118 -- when you click the Save button the second time, the barbershop progress meter starts spinning and the status bar reads "Attaching" but it never stops. You can, however, click the Close button, get the warning that "a message is being sent" and Quit, and the first saved draft is still in place, with the image. A difference: in TB, typing anything after the first save 'resets' the window so that the second save maintains the image. In Moz, typing anything after the first save doesn't reset; the second save continues to hang.

=> Core

(In reply to comment #0) Just another way to see images disappear in Thunderburd (versions 1.0-1.5b2, Win XP): 1) Create a new message 2) Type some text 3) Insert an image from disk 4) Save the message 5) Drag-and-drop the image to another locatoin in the message. The image disappears, only placeholder is visible.

I use TB 1.5.0.7. The bug still exists. Even TB 1.5.0.7 randomly hangs when saving a draft with images that has been previous saved. Moreover, the saving of a draft with images more than one time creates another copy of the message in the draft folder. In some case, after repeated saving, three or four copies of the message has been saved, even if one make changes in the same message. Reproducible: Always Steps to Reproduce: 1. Start a new mail 2. paste some images into it 3. Save 4. Make some changes to the mail 5. Save a second time 6. Make some changes to the mail 5. Save some more times 5. Close the window of the mail you have been editing 6. Open the specifik mail again Actual Results: Images disappear Drafty folder list several copies of the same saved mail

(In reply to comment #4) Sorry, I forgot: > Actual Results: > Images disappear > Draft folder list several copies of the same saved mail It is impossible to make a new save since TB (the windows about the completion of the saving operation) hangs.

*** Bug 319818 has been marked as a duplicate of this bug. ***

I tried this with a trunk build, and didn't have any problems. Does this still happen on the trunk?

(In reply to comment #7) > Does this still happen on the trunk? TB 3a1-0915, SM 1.5a-0925, Win2K: following the steps in comment 0, no, I don't see this. However, if you click Save twice *after* reopening the draft, you get a hang with "attaching" in the status bar (bug 319818, and like comment 1 here). I guess I duped 319818 a little hastily, it's not exactly the same thing.

click save twice quickly, or waiting until the save finishes and then clicking save again? And was this imap or local drafts folder?

Click and wait and click again. Local folder. I just reopened bug 319818, which is about that specific problem -- related to this one, but not the same thing. This one WFM, trunk and branch (I just retested with TB 2a1-0920).

No response from reporter => WFM