Closed Bug 532395 Opened 15 years ago Closed 8 years ago

Sending reply to (or forward inline of, or edit draft of) existing HTML message with embed images fails with never-ending error message: "attaching..."

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 53.0

People

(Reporter: michal, Unassigned)

References

(Blocks 3 open bugs,
URL
)

Details

(Whiteboard: [Before commenting, Read Comment 114, and see bug 1201782 if your problem started in TB38][this bug collects cases other than bug 453196, bugs pointed in bug 453196, and bug 817245])

Attachments

(3 files)

Testcase 1: Sample message source
17.79 KB, text/plain
Details
Testcase 2: message from "Duden" editors (with 1px-inline-image-part embedded/referencedin HTML body multiple times)
61.39 KB, text/plain
Details
Example message that is replied to, to replicate issue
10.24 KB, text/plain
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1) Gecko/20090630 Shiretoko/3.5 Build Identifier: Gecko/20091126 Shredder/3.0 If a message I've received has some graphics it takes forever to replay to it if I choose to keep the original body as part of my reply. The workaround is to cut the whole message from "composing window", save the empty message as a draft and then copy the body back in. After that sending takes just a moment. And it ends successfully!!! I haven't tried sending the message in offline mode yet. Details: The program: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091126 Shredder/3.0 I have it installed on: Microsoft Windows 7 Professional (6.1 Build 7600). Every time I try to quit the e-mail application it pops up again after a few seconds. I'm using IMAP4 account if it is a hint for you. Regards, Michal Reproducible: Sometimes Steps to Reproduce: 1. Receive a rich HTML message using IMAP4. 2. Reply to it with the most part of the original body included in the present body. 3. Press send button. Actual Results: "Attaching message" message stays displayed forever. Expected Results: Reply message sent. I wish it sent the reply.
Can you provide a message that does that ? (use the add attachment link above)
If I tried to replay to this message I could not send it because of "attaching..." message displayed forever. Almost every html bodied message does the trick - the longer the worse it behaves.
Same thing happens if I sent messages with attachments. First it keeps saying "attaching..." then I stop it and hit send button againt then it works OK. I've been using Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 for some time now. The behaviour doesn't change.
please check to see if this is a duplicate of bug 389132
Whiteboard: dupme
It is not a 389132 bug duplicate unless one refers to sending one message as "marking 10 or more message to report as spam".
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.17) Gecko/20110123 SeaMonkey/2.0.12 Confirming the same happens to me in SeaMonkey. Clearly not a dupe to bug 389132 as this is about multiple messages. pi
Status: UNCONFIRMED → NEW
Ever confirmed: true
Just reply to this message. It will hang forever. SeaMonkey does not give a clear reason. What is it "attaching"? Since everything is available on screen it needs to be available in memory at least. pi
This is a very serious problem, and getting worse every day. We've been experiencing this for the last year or so, but it seems to be getting to be a much bigger issue the last few months, so I decided to see if there is a bug open Please, devs, fix this.
I've just been trying with both the test cases and can't reproduce on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0a2) Gecko/20110504 Thunderbird/3.3a4pre I think we need more info as to what sort of html messages do it - e.g. many links, big images etc.
It's nothing to do with the number of links or size... I'm not on a dev build... so maybe its fixed there? I have two message right now that fail every time - want me to forward one as an attachment to you?
How about attaching them to this bug ?
Because apparently once the message has been saved out as a separate standalone file, the problem graphics are 'missing' to the point the problem disappears. I also just did some testing trying to figure out how to get a message to someone that easily reproduces the problem, but I can't - because the message simply will not send (or even save as a draft), because of the problem!? I can forward the message as an attachment, or save the source, but there are already two samples of problem messages attached to this bug, so I didn't see how adding another would help anyone, but I'll be happy to if you really think it will. I would be happy to provide remote access to a developer to demonstrate the problem and let them gather whatever debug details they might need to debug this further. Oh, one more tidbit... I always Reply from the main window, I do NOT open messages in separate tabs or windows, but, if I open the problem message in a separate window, and File > Save As to a file, then open that standalone message and reply to it, the reply sends just fine, but the problem graphics are missing. Also, if I try to save it as a draft prior to sending, I get an error about checking my Mail/Newsgroup settings, but that's a separate bug and not one I'm too concerned about.
Oh, one last thing... Even if I do forward the message as an attachment to someone, if you open the attached message and click Reply, again, the problem graphics are 'missing' and the problem is not evident (ie, the reply sends fine, but without the graphics). In this case, the graphics are tiny facebook and twitter... graphics... Hmmmm... standby one...
Ok, I just remoted into my home PC, and the same problem message works fine, so this is obviously something to do with our network... probably our Intrusion Detection appliance (which also does some rudimentary web content filtering). My apologies to the developers, and sorry for the noise...
So, one last question... is there anything TB could do to simply ignore links to graphics that are unable to 'reach their destination/targets'?
Ok, another update... This problem apparently only happens on IMAP accounts in folders that are NOT set to offline use... If I set the folder to Offline Use, then 'Download Now' the messages for that folder, the problem disappears???
I saw this same problem under a simpler set of conditions: I copied a picture from an old message and pasted it into a new message. The "attaching...." window popped up pretty soon after that, and sending the message just left it in the hang state, so I canceled the send and deleted the picture from my message. What worked was to save the picture to a file and then insert the file into the new message. It looks to me like the message composer doesn't handle embedded images correctly; you have to go through the specific protocol of inserting an image from a file.
I have observed the same problem. * Was replying to HTML message. HTML message had just few links, no complicated HTML within. * IMAP Inbox folder, marked for offline use. * Unfortunately, I have removed the original message before pressing "Send". * Win7 x64, TB v10.0.
I have observed this behavior, too. In fact, so have many other people: https://getsatisfaction.com/mozilla_messaging/topics/message_status_attaching_stalls https://getsatisfaction.com/mozilla_messaging/topics/one_email_message_not_going_out_status_attaching https://getsatisfaction.com/mozilla_messaging/topics/status_attaching_message_my_email_wont_send https://getsatisfaction.com/mozilla_messaging/topics/status_attaching https://getsatisfaction.com/mozilla_messaging/topics/status_attaching_when_sending_email The last link provides the closest thing to a workaround: delete the inline attachment from the original message. This has nothing to do with IMAP. I don't use IMAP and this issue has plagued me for quite some time now. This seems like very basic functionality that should have been nailed-down years ago. Perhaps this is a regression of some kind.
Must be a regression as it happened maybe once a week pre 13, now happens several times every day to me. Removing inline image usually works for me.
Please delete my last two comments. Smartphone went bezerk. I'm on rel 13.0.1 and it is happening to me daily now. I never experienced it before rel. 13.
1. navigate to your temp directory in windows %temp% ... how many files are in the directory? 2. if you do it a second time with the same message without shutting down thunderbrd, is it just as slow? (In reply to Charles from comment #12) > Because apparently once the message has been saved out as a separate > standalone file, the problem graphics are 'missing' to the point the problem > disappears. > those of you who see the problem - are you unable to reproduce this with the testcases attached to the bug? (I cant' reproduce)
I see this problem frequently but I can't reproduce it with the test cases (I opened the "Duden-Newsletter vom 18. März 2011" message attached above in comment 7 from Boris 'pi' Piwinger and I was able to reply to it and send the reply to my e-mail address without encountering the bug). Actually I'm getting this bug almost everyday but I never could reproduce it on purpose. Here is what I noticed: - This bug is not new (I've been seeing it for many months or years) but seems to be more frequent now than it used to be. It doesn't happen frequently compared to the number of messages I edit, but I get it at least twice a week. - It happens only with messages that have got one or more attachments, either attached files or HTML-embedded images. - It can happen either when the images or files have just been attached for the first time or when they are included into the message that is being replied to and quoted. - It also happened to me sometimes, although not recently, when editing a sent message, containing images, with the "Modify as a new message" function. - When it happens, it is not possible anymore to save nor send the message (it keeps saying "attaching..." in the status bar if you try to save or send). - I have autosave turned on and set to 3 minutes, so often I see the problem when TB tries to autosave a message that I am writing. - When it happens, deleting the attached image(s) or file(s) and reattaching it/them always solves the problem. - Apparently only one of the attachments is causing the problem, because the problem is usually solved also when only some of the attachments or images are deleted (I delete them one by one until the problem is solved). I suppose it means that only one attachment or image had been corrupted in a way or another. - If the faulty embedded image is in the original message that is being replied to, then, if you open a new reply to the same original message, the new draft reply will not have the bug (even you keep the buggy draft reply open at the same time) and then you can copy-paste whatever text you want from the buggy draft to the new similar but non-buggy draft message. - This is not related to IMAP. I use POP and have this bug on my POP accounts. I use Thunderbird 13.0.1 and Windows XP.
I've just had the issue again (cannot save or send the draft message, hanging with "attaching..." message in status bar). It happened when I was doing a forward on a message which has got one .doc attachment (464 Ko) and one embedded .gif image (8 Ko). 1. %temp% size is 1.62 Go, with 2622 files and 231 folders (and there is 168 Go free space on this disk). 2. I did it a second time with the same message without shutting down Thunderbird (and without closing the buggy message) and I did not get the problem. Also I had already done a forward from the same message earlier today in the same Thunderbird session, and it had worked fine. 3. Then I deleted the embedded gif image in the buggy message (which was still impossible to save or send), and then I was able to save it and send it. If I look at the source from the original message with which I had the bug once when I tried to forward it, the gif image is attached in the following way: ------_=_NextPart_002_01CD5B92.0143662E Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: <image001.gif@01CD5B81.AAF90E10> Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif" Content-Location: 1_multipart%3F1_multipart%3F2_image001.gif (...) ------_=_NextPart_002_01CD5B92.0143662E-- If I look at the source from a successful forward I did on this message, Thunderbirds attachs this gif image in the following way: --------------030908090803040003010203 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <part2.07000407.08070805@gmail.com> (...) --------------030908090803040003010203-- I cannot find the source from the unsuccessful forward I had done on that same message (I believe it has been overwritten in the %temp% directory when I removed the image at step 3 described above). I have the following system: User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0
François, please delete everything you can in %temp% ... can you now reproduce the problem?
I have now deleted all files in %temp%. I'll let you know if the problem happens again.
I had the problem again today and when it happened my %temp% folder was only 33.3 Mb, with 26 files and 8 subfolders in total. The following detailed description of this issue I had tonight provides some additional information about the bug because I checked several other things step by step: The message with which I had a problem today was again a message with an inline gif image (8ko) which was contained in the original message to which I was making a reply. The issue happened as follows: 1. My draft reply could be autosaved many times in the draft folder while I was writing it (for 1 hour), 2. but after attaching a word document and trying to send the message, then the message could not be sent (freezing forever with "attaching..." message in the status bar, and also in the "sending message" little window), 3. then I looked at the source of the last draft that had been autosaved from this message (see an extract from this source below), 4. then after 10 min I canceled the sending (I clicked "cancel" in the little sending message window that was stalled with "attaching..."), 5. then, surprisingly, I could save this draft once, (so apparently the problem had temporarily disappeared!) 6. but then I had the problem again when trying to send it (stalled with "attaching...")! 7. then also it was not possible to save it anymore (still getting the "attaching..." forever), 8. then I looked at the source of the last draft from this message that had been saved at step 5 (see an extract from the source below) 9. then still not possible to save or send 10. then I deleted the inline gif image from the message 11. then I could finally send the message!! (see an extract from the source below) *** At step 3 above, the last saved copy of the draft message before it became impossible to send, in the draft folder, had the gif image embedded as follows: Content-Type: multipart/related; boundary="------------000602030109070005080306" This is a multi-part message in MIME format. --------------000602030109070005080306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> (...) </body> </html> --------------000602030109070005080306 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <part8.06070108.04090203@gmail.com> (...) --------------000602030109070005080306-- ** At step 8 above, the last saved copy of the draft message, in the draft folder, before it became impossible to send or save, had the gif image embedded as follows: Content-Type: multipart/mixed; boundary="------------000907060306050305070608" This is a multi-part message in MIME format. --------------000907060306050305070608 Content-Type: multipart/alternative; boundary="------------030007010108040102020802" --------------030007010108040102020802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit (... message in text here ...) --------------030007010108040102020802 Content-Type: multipart/related; boundary="------------070805000104040804030602" --------------070805000104040804030602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> (... message in html here ...) </body> </html> --------------070805000104040804030602 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <part8.06020504.02030406@gmail.com> (... gif image here ...) --------------070805000104040804030602-- --------------030007010108040102020802-- --------------000907060306050305070608 Content-Type: application/msword; name="12919501.ACT - =?ISO-8859-1?Q?annot=E9_FRC=2Edoc?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0*=ISO-8859-1''%31%32%39%31%39%35%30%31%2E%41%43%54%20%2D%20%61; filename*1*=%6E%6E%6F%74%E9%20%46%52%43%2E%64%6F%63 (... word document here ...) --------------000907060306050305070608-- ** Finally at step 11, when this message was sent its source was as follows (as it appears in the sent folder): Content-Type: multipart/mixed; boundary="------------090508000707050901090706" This is a multi-part message in MIME format. --------------090508000707050901090706 Content-Type: multipart/alternative; boundary="------------030604060902030602070006" --------------030604060902030602070006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit (... message in text here ...) --------------030604060902030602070006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> (... message in html here ...) </html> --------------030604060902030602070006-- --------------090508000707050901090706 Content-Type: application/msword; name="12919501.ACT - =?ISO-8859-1?Q?annot=E9_FRC=2Edoc?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0*=ISO-8859-1''%31%32%39%31%39%35%30%31%2E%41%43%54%20%2D%20%61; filename*1*=%6E%6E%6F%74%E9%20%46%52%43%2E%64%6F%63 (... word document here ...) --------------090508000707050901090706--
Could it be a dupe of bug 501298 ?? See STR and comments (and my own STR / comment on 25)
I've had this issue for a while now (6+ months), definitely never used to occur, but I can't tell what version started with the issue. I'm on v13.0.1 and Mac Lion. I receive an email with a signature image. I reply to it (with a copy of the original message below my reply). I get the "attaching" message which never disappears and the message never gets sent. To resolve, I delete the image from the original message copied below my new message and can send no problem. Interestingly, if I then return to the original message and reply or forward, it sends fine. As if it's the initial message storage of the temporary image and once some action is performed on the original email it sorts itself out. Another observation is that if I delete the image to successfully send it, when I get a reply from the same person (with their signature image repeated again) I have no problems replying - with no "attaching" message box. So again, firming up that it's only the initial message that causes the issue. Attached images and embedded images (images dropped within the initial message) have never caused the issue, just inline images - normally always triggered by logos in peoples signatures. Here's the image html in question (via view source): <img height=3D"40" width=3D"87" = id=3D"9280c261-715f-4ebe-a50b-0ade92d11e69" apple-width=3D"yes" = apple-height=3D"yes" = src=3D"cid:5037E832-390E-48D6-839E-943983DC6FEA@lan"> And at the end of the message source reference to the gif: --Apple-Mail=_A8B95EE8-40FE-4E68-A7F0-ECF145ED1105 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=Email_logo.gif Content-Type: image/gif; name="Email_logo.gif" Content-Id: <5037E832-390E-48D6-839E-943983DC6FEA@lan> R0lGODlhVwAoAMQQAH2/4LHY7Var10ml1PL5/Dye0eXy+djs9orF5HC43b7f8KTS6ZfL5svl82Oy 2i+Yzv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA ABAALAAAAABXACgAAAX/ICOOpBgcUKqubOtCy/Mkb23fqSPIMgnsjwLAgCtCHDyjsphIsgxIWWBZ iz0A1KyL4WwBeFMti0AQm1NcWS36IJ7f7/SjduBh4Xit3AacqwgBIg0tBgsMC4MpBgEACGMKJm5j AWEQB4eSN3s1CDyJnQ4IBQ8DKCmdA0ANCn0OKwwFQkCNDgMMAU0Prg1sBaaaXVueR1cpB6MFZQGk KTENhVGupzKmXzwPDH0CCQUIsDI0OJsvcg3LD2Up1lNIA+kDiQ0y0gbgKvU9DlMKPAnp8kGKjBMm o8GABwJWnHNAIJcAIgf+zUtxjsEKIL8ASlMRrMbAFp1k4LtGsgHAIJUg/2hsZk9FFEkrV3QkN3PF wRkxX5yTcUflREsyCvyRMWBFzhQ1W3w06gmgUBsNRvVIkdPanS++mOpikZTFUhVAHI1UcIMAkKdH Qw446OAX1Z8c1YhLalXFTXcKhTogC4HAzbdb+34RYLJBOhZHIchIiCNkGxaspqrYOSAAgQNfFkAA sBFVCn4BIaRJ6QL0089BNVkjKgKBg1EDEGRSR1KGZtE4A8Q60ODbvEM8CjgYPjxBGN+6AhhA7sAi uRIlFLht0YDz8AWSAhB3MEQldAYE2NSeIbqE8u950rcIv237zQfT1adfxGD2igMCkrWwkkg9/QQO JHBIfEUg0Ed/LezAGP8Ly5yWBy+LecNAFAXssISBw7wAxhMH8YUHAdYQ9kQufiyhyho86GOSKPCo F0VPXsi1RBQIXvYHAu+RAgBpcKSBF4pZ0KjQRvLVMBKPiJWohJB2EVmkC45l0cB0BEy5ApObBfaE YSzwdpgxKBiAIFUmHQaEkzZgGNiEKV5ZkGC1wZPATYnUkqECOOri1B2wpMJTGTw4YkSegfV2E5FC BnAWcQpUl+ECqw1SBw8CvIfFF3eckxAPzhkBGpFHMZkYMQ8gyCQBciSgAAC+WGEmNf0scVSob/qk pUu15pCrU1+y9QpPlMoKl62I1joqlqT2d9Sk4xHFg301zDqsqMPqWqrHm9cCBipPLzjWaQ1VEqtV sdkem2uyKkiL0AsjFQDtCgnQoC658VSLLq7Zipvusy9YgdCXLHxBFkALQrAQtvWum0I6UaR0orYr EBDrfdKsJkB8DTEDlG0QGLAakUB4yAMKARQFgVpElMyDhwevsFoCRKCKjQoKWBqASatK1Wkf8/iL TQOOCaBclkEgEcZJnIqngMo9PLMwz4G2gItUlAqIwGEHRJHAIPI4sAAK2xE3BYijCOChwQcN0F0t O14W9nCVoAqE2omEAAA7 --Apple-Mail=_A8B95EE8-40FE-4E68-A7F0-ECF145ED1105-- --Apple-Mail=_7BC061B3-47FB-4E39-99E5-26725567FC5D--
(In reply to Peter Lewis from comment #31) > I've had this issue for a while now (6+ months), definitely never used to > occur, but I can't tell what version started with the issue. I'm on v13.0.1 > and Mac Lion. > > I receive an email with a signature image. I reply to it (with a copy of the > original message below my reply). I get the "attaching" message which never > disappears and the message never gets sent. There are various bugs for (inline) images, some of them fixed, but not yet released. E.g. Bug 754655 (fixed for TB14) Bug 671440 (fixed for TB16) Bug 501298 (and more)
I've checked those links (bug reports) and the others mentioned in this thread and none relate to the issue better than this bug thread. Possibly when I refer to "inline" I'm creating misunderstanding. I can replicate when I receive images in signatures, where the image is part of the html, but whenever an image is attached (however it's attached) it is fine (be that inline or as an attachment). It never occurs when I'm sending a message, just replying or forwarding. And always with the same "attaching" message that never completes.
The issue happened to me twice today. In both of those cases I was writing a reply to a message which had got one .png inline image (inside the signature of the message to which I was replying). ONE VERY INTERESTING FACT is that in both of those cases AN EMPTY .tmp FILE WAS MODIFIED in the %temp% folder at the time when the issue occurred (hanging forever with "attaching..."): * first issue (happened at 10:28): - filename : nsmail-15.tmp - size : 0 bytes - created : Wed. 11th July 2012, 10:22:37 - last modified : Wed. 11th July 2012, 10:28:37 * second issue (happened at 16:14): - filename : nsmail-16.tmp - size : 0 bytes - created : Wed. 11th July 2012, 16:02:48 - last modified : Wed. 11th July 2012, 16:14:48 My autosave is set to 3 minutes, so the timestamps show that for the first message for which I had the issue, the draft reply could successfully be autosaved twice (at 10:22:37 and at 10:25:37) but failed to autosave on the 3rd time (at 10:28:37). I did not do anything in the meantime between the successful autosave and the failed autosave, except writing text in the draft message. For the second message for which I had the issue, the draft reply could successfully be autosaved 5 times (at 16:02:48, 16:05:48, 16:08:48, 16:11:48) but failed to autosave on the 5th time (at 16:14:48). And I have indeed an autosaved draft of this at 16:11 in my draft folder. Here is an extract from the source of this 16:11 last successful autosave of this message (obtained with View->Source code of the message): From - Wed Jul 11 16:11:48 2012 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: (...) User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 (...) Content-Type: multipart/related; boundary="------------050200030205040301050905" This is a multi-part message in MIME format. --------------050200030205040301050905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> (...) <img src="cid:part1.02090704.02010100@gmail.com" v:shapes="Image_x0020_3" align="left" height="116" hspace="12" width="102"> (...) </html> --------------050200030205040301050905 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: <part1.02090704.02010100@gmail.com> (... image code here ...) --------------050200030205040301050905-- In addition, I have just looked at what happens in the %temp% folder when a successful autosave occurs: it creates 2 non-empty files, for instance one named "nscopy-7.tmp" and one named "nsemail-8.eml", but it does not create any "nsmail-xx.tmp" file, or if it does, it deletes it before I can see it. This is strange, because when I had the problem at 16:14, it modified the empty nsmail-16.tmp file at 16:14:48, which had been created at 16:02:48 as timestamp shows, so this nsmail-16.tmp existed already after the previous successful autosave. So, since successful autosave does not seem to normally create "nsmail-xx.tmp" files, I assume that maybe this nsmail-16.tmp file had another name just before and had just been renamed and made empty when the issue occurred at 16:14:48.
(In reply to Peter Lewis from comment #33) Peter, thanks for your valuable and fast feedback. > I've checked those links (bug reports) and the others mentioned in this > thread and none relate to the issue better than this bug thread. Possibly > when I refer to "inline" I'm creating misunderstanding. I can replicate when > I receive images in signatures, where the image is part of the html, but > whenever an image is attached (however it's attached) it is fine (be that > inline or as an attachment). When we say "inline" images, we usually mean HTML messages with embedded images like <img src="CID:12345@12345">, where 12345@12345 corresponds to a part name within a multipart/related message structure. As opposed to that, "attached" images (file attachments that happen to be images) might look similar in the message structure, but they would usually be part of a multipart/mixed structure and the method of attaching is different (attached as a file attachment via TB's UI), and they are not embedded in the HTML body part of the message when composing. However, *recipient* might choose to *view* such previews of attached image files "inline" with the message body, which (for the purpose of this bug and friends) is *not* considered an "inline" image. > It never occurs when I'm sending a message, I think you mean (pls correct me if I'm wrong): It never occurs when composing a new message from scratch, i.e. using "Write" (Ctrl+N)... > just replying or forwarding. And > always with the same "attaching" message that never completes. Peter, can you file the exact wording of one such error message as a comment here?
(In reply to François R-Champigneul from comment #34) One more thing. I had let open the message which had the issue at 16:14:48. After more than one hour, it was still hanging with "attaching..." in the status bar, but when I tried to save it again (with CTRL-S), then it worked! and it created 3 files in the %temp% folder: nscopy-7.tmp, nsemail-8.eml and nsmail-20.tmp, all with the same timestamps: - filename : nsmail-20.tmp - size : 6,16 Kb (6 317 bytes) - created : Wed. 11th July 2012, 17:38:40 - last modified : Wed. 11th July 2012, 17:38:40 The nsmail-20.tmp file is in fact the .png image of the message.
Michał (reporter), can you post the exact wording of the error message mentioned in comment 0? Per comment 0 and many subsequent comments, this bug seems to involve embedded "inline" images in HTML message body as explained in comment 35. Furthermore, I don't see anything about "attaching messages" (i.e. forwarding of existing messages). -> adjusting summary accordingly. Testcase 2 of attachment 520140 [details], has an invisible 1-pixel image (among other images) which is repeatedly embedded many times in the HTML body as a spacer between sections: ------=_Part_1572868_13332456.1300420278572 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <image.1300402863640.695@121a11c67b49e80f4dd406b4e06> R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw== ------=_Part_1572868_13332456.1300420278572 So the failure of that testcase is likely a duplicate of Bug 754655. I have a strong feeling that the original report and many of the reports in this bug are a duplicate of one of the bugs mentioned in comment 32 (or similar bugs related to inline images): Bug 754655 (fixed for TB14) Bug 671440 (fixed for TB16) Bug 501298
Summary: Sending reply to an open message takes never ending "attaching message". → Sending reply to (or forward inline of) existing message with inline images fails with error message: "attaching..."
Attachment #520140 - Attachment description: Testcase e-mail message → Testcase 2: message from "Duden" editors (with 1px-inline-image-part embedded/referencedin HTML body multiple times)
As a side note, afasics, the multipart structure of testcase 2 (attachment 520140 [details]) is not strictly correct, e.g. the sequence of multipart/related and multipart/alternative should be the other way round, and content-disposition for images is missing. Perhaps someone can file bare bones part structure of attachment 520140 [details] in a comment, or reduced testcase as attachment.
Summary: Sending reply to (or forward inline of) existing message with inline images fails with error message: "attaching..." → Sending reply to (or forward inline of) existing message with inline images fails with error message: "attaching..." (multipart/related, multipart/alternative)
Attachment #415849 - Attachment description: sample message source code → Testcase 1: Sample message source
Attachment #415849 - Attachment filename: sample_message_source.txt → sample_message_source.eml
Attachment #415849 - Attachment mime type: text/html → text/plain
Hi Thomas, > It never occurs when composing a new message from scratch, i.e. using "Write" (Ctrl+N)... Correct > Peter, can you file the exact wording of one such error message as a comment here? Popup Panel... Status: Attaching ... Progress: (graphical bar) Status bar at bottom of application... Attaching ... (in bottom left) progress bar (in bottom right) I get no conclusion or error as it will last forever (there are no pop under message boxes or indication of errors). I'll see if I can attach the full source of the message prior to me attempting to reply.
This is the source of the message I received to which I responded to (therefore triggering the error. There's no way I know of to show the source of my reply as I can never send it without first removing the signature image. I've removed email addresses and the large attachment data. The issue isn't related to the file attachment, as can be replicated without it, and when replying it's not attached to the message. Hopefully something can be gleamed from it.
The following quote, which I posted a while ago, might offer a clue. The point is that the message that hangs isn't always "Attaching ..." Sometimes it's "Attaching xxxxxx.xxx." It shouldn't be hard to track down the point in TB where random file names are generated. "Often when I reply to an email that contains images or signatures, the send hangs saying "attaching xxxxxx.xxx" where the file is some random name like, recently, bdgggjdd.png or fcaafgfh.png. The name changes upon repeated attempts. Sometimes there is no file name."
Phenomenon of this bug was persistently observed in duplication test of bug 766495. (In reply to Dmitry Katsubo from comment #18) > I have observed the same problem. > * Was replying to HTML message. HTML message had just few links, no > complicated HTML within. > * IMAP Inbox folder, marked for offline use. > * Unfortunately, I have removed the original message before pressing "Send". Thanks for sure "Steps to Reproduce" with IMAP. (Case-1) IMAP, original mail is deleted & expunged If IMAP, "image in original mail of Reply/Forward as inline" is represented like following at composition window. - Original HTML mail with embed image in IMAP folder. UID=uuu (Oreder Receved column value, if IMAP folder) Part=1 : multipart/related Part=1.1 : text/html, <img src="cid:cid-of-a-image"> Part=1.2 : image/xxx, Content-Id: <cid-of-a-image> - Image location of the image by Reply/Forward in inline(HTML mode). > imap://user-id@imap.gmail.com:993/fetch%3EUID%3E/INBOX%3Euuu?part=1.2&filename=magenta-32x32.PNG > A > | > UID of original mail in IMAP folder ---+ If the original mail(UID=uuu) is deleted & expunged(by Compact) before first save as Draft or Send Later/Send without save as draft, mail of UID=uuu can't be obtained. If this happens on image, Tb looks to wait forever(Attacching... message), or looks to fail(Save Error message), upon saving as draft/mail sending. If Compact happens on local mail folder, similar problem to Case-1 can occur. (Case-2) local mail folder, offset of original mail is altered by Compact while composing, or original mail is removed by delete & 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-a-image"> Part=1.2 : image/xxx, Content-Id: <cid-of-a-image> - Image location of the image by Reply/Forward in inline(HTML mode). > mailbox:.../Inbox%3Ennn?part=1.2&filename=magenta-32x32.PNG > 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-2-a) data at Offset=nnn : doesn't exist (file size after Compact<nnn) => Attaching..., Save error, null image part data, and so on (Case-2-b) data at Offset=nnn : mid of different mail => Attaching..., Save error, null image part data, and so on (Case-2-c) data at Offset=nnn : valid/different mail (Case-2-c-i) the valid/different mail doesn't have part=1.2 => Save error, null image part data, and so on (Case-2-c-ii) the valid/different 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 mail has part=1.2, and valid image data => image data of different mail is silently used by Tb If same thing as Case-2 happens on Edited draft mail in local Drafts folder, same problem as Case-2 occurs on draft mail. (Case-3) 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-a-image"> Part=1.2 : image/xxx, Content-Id: <cid-of-a-image> - Image location of the image by Edit draft(HTML mode). > mailbox:.../Drafts%3Ennn?part=1.2&filename=magenta-32x32.PNG > A > | > +--- Offset of original mail in local Drafts folder If data at Offset=nnn is changed by Compact Folder, same phenomena as Case-2 surely happens. (Case-3-c) data at Offset=nnn : valid/different draft mail (Case-3-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 (Case-2-c-iii) & (Case-3-c-iii) is phenomenon of bug 766495. 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 image only phenomenon.
To all problem reporters for local mail folder case. Do you enable auto-compact? If yes, do you see your problem even with mail.purge.ask=true(restart of Tb is required) and "Cancel" reply to prompt before auto-compact? FYI. Auto-compact related setting. mail.prompt_purge_threshhold = true(auto-compact is enabled) / false(disaled) mail.purge_threshhold_mb = MMM (in Mega bytes) mail.purge.ask = true : Pprompt before auto-compact is shown. false : Auto-compact runs silently, without confirmation. Note: Restart of Tb is mandatory if you changed this option. Following option is useful to know when draft save happened. Copies&Folders of each Identity, [ x ] Show confirmation dialog when messages are saved.
I have always had auto-compact disabled, and am still seeing the problem with TB 14.0. (Options > Network and Disk Space > Compact Folders when it will save over... is unchecked.) There definitely seems to be a time element here. If I reply immediately to an email that has embedded images, it sends without a problem. However, if I take too much time composing my reply (several minutes), I run into the "attaching..." problem.
Perhaps someone has already suggested this, but given comment 44, perhaps the issue is related to auto-saving. I have experienced this issue for the last few major releases and I use the auto-save feature, and it's configured to save the draft to my local "Drafts" folder every five minutes.
I just turned off auto-save and will let you know if it makes any difference. May take some time as I try various things to get the problem to recur.
(In reply to emeadows from comment #44) > I have always had auto-compact disabled, and am still seeing the problem > with TB 14.0. > There definitely seems to be a time element here. If I reply immediately to > an email that has embedded images, it sends without a problem. However, if > I take too much time composing my reply (several minutes), I run into the > "attaching..." problem. Because auto-compact is irrelevant in your case, it may be similar problem to bug 638390. (old draft is not deleted if auto-save and Manual draft save/Send Later/Send occurs at same time) Auto-Save Manual draft save/Send Later/Send (0) Latest draft mail : Offset(local)/UID(IMAP) = nnn1 Image location at Reply/Forward mail : mailbox:.../Drafts%3Ennn1?part=1.2&filename=... imap:.../Drafts%3Ennn1?part=1.2&filename=... (1) Auto-save starts .../Drafts>nnn1 will be deleted .../Drafts>nnn2 will be created (2) User requests Save or Send .../Drafts>nnn1 is used for image (3) Auto-save deletes old .../Drafts>nnn1 (4) Send(or Save) tries to use .../Drafts>nnn1 => Not found => Attaching... -------------------------------------------------------------------------------- (5) Auto-save creates .../Drafts>nnn2 (6) After successful Send(or Save), deletes .../Drafts>nnn1 Bug 638390 is problem when contention between (3)/(5) and (6). Because (a) while auto-save is in progress, Save/Send can be requested, and because (b) even after Send(or Save) is requested by user and is in progress, auto-save is invoked by Tb, contention like above may occur.
Thanks Ben and WADA. It looks like disabling auto-save solved the "attaching..." problem for me. I've been testing for several hours now with an email that was causing this problem and so far it's been fine. By now the problem most likely would have recurred - it was so predictable.
Summary: Sending reply to (or forward inline of) existing message with inline images fails with error message: "attaching..." (multipart/related, multipart/alternative) → Sending reply to (or forward inline of) existing message with inline images fails with error message: "attaching..." (If replied/forwarded/previous-draft mail is deleted or its offset is altered while mail composition, Send/Save can't find the mail)
What is the best reproducible STR (bug and comment #)?
It looks to me a dupe of bug 501298 See STR and comments (and my own STR / comment on 25)
Cmon already, this bug has been in TB for ages, and its so so easy to reproduce. To reproduce.. just reply to an email that has an image in the signature... Its sooooo anoying !
(In reply to Kent James (:rkent) from comment #50) > What is the best reproducible STR (bug and comment #)? Read comment #42, please. STR by comment #18 surely produces phenomenon of this bug with IMAP folder/mail. I could see same external symptom as one reported to many comments of bug by STR which I wrote in comment #42. But I don't know whether "other than comment #18" is same phenomenon what I cited in my comment or not. I don't know what is best STR. IIRC, similar problem like next was reported to other bug, (1) Attach a local file to composed mail or embed local image file to HTML mail (2) Delete the local file before first draft save by auto-save (3) Send => error message is shown, or endless "Sending..." message
FYI. If edit of a draft mail is invoked multiple times at same time, following occurs. 1. Edit a draft mail with embed image => compose window-1 2. Edit the same draft mail => compose window-2 3. Save at compose window-1 => original draft mail is deleted 4. Save at compose window-2 => Attching... because original draft mail doesn't exist Note: Above problem doesn't occur if IMAP Drafts folder with IMAP delete model of "Just mark it as deleted" and if Compact is not invoked after "delete==store flag \Deleted", because original mail of UID=xxx is just marked as \Deleted and is shown with strike-thru line at thred pane.
duplicate of bug 468159 ?
(In reply to Thomas M. from comment #55) > duplicate of bug 468159 ? WADA, I recommend to make bug 468159 a duplicate of this bug, because this bug 532395 has more quality analysis provided by WADA :) I think the bugs look similar enough, and we cannot expect all reporters to realize all the details of their problem (like deletion, offset change by compaction etc.), so there is a good chance they are seeing the same problem as this bug. Some reporteres of bug 468159 even said it is not always reproducable. I think after solving this bug, we can then see if any complaints remain.
I'd be in favor of the dup. but it should somehow be noted (whiteboard?), if bug 468159 is correct, that the original issue is a regression in version 2. And also, that some recent change has made the problem worse. Also, I thought we had a bug where someone said they knew how to fix this. Did I dream it?
WADA, thank you for detailed analysis of some known causes. Can you give some short general ideas/directions how these known problems can be solved?
(In reply to Thomas M. from comment #55) > duplicate of bug 468159 ? How can this bug be dup of that bug? How can that bug be dup of this bug? That bug says: "Attaching ..." and hang occurs on any "Forwarding e-mail with any embedded image". If bug summary of that bug is understood normally, it implies that "any forwarding of any mail with any embed image" always produces phenomenon of "Attaching ..." and hang. In contrast to it, any problem report in this bug is phenomenon of "Attaching ... upon a forward of HTML mail with embed image but with unknown condition(i.e. not always)" except comment #18 in which condition is very clear and apparent.
(In reply to WADA from comment #59) > (In reply to Thomas M. from comment #55) > > duplicate of bug 468159 ? > > How can this bug be dup of that bug? > How can that bug be dup of this bug? Maybe WADA, as an experienced contributor, is disappointed that we don't see what appears obvious to him; but surely he does not intend to blame Thomas M., who is still new to Bugzilla, for being helpful and pointing out potential duplicates. Especially given that Wayne and me, both experienced contributors, also agree that this might very well be a duplicate... ;) > That bug says: "Attaching ..." and hang occurs on any "Forwarding e-mail > with any embedded image". If bug summary of that bug is understood normally, > it implies that "any forwarding of any mail with any embed image" always > produces phenomenon of "Attaching ..." and hang. Unfortunately, we have no reason to assume that the summary or description of bug 468159 have been carefully formulated with great precision (see bug 468159, comment 13). In fact, many summaries are not very precise (unless WADA has touched them, which usually makes them a lot more precise and a bit harder to read... ;). > In contrast to it, any problem report in this bug is phenomenon of > "Attaching ... upon a forward of HTML mail with embed image but with unknown > condition(i.e. not always)" except comment #18 in which condition is very > clear and apparent. WADA, I think it might be misleading and error-prone to assume that everybody works with the same level and awareness of detail and precision as you do. So perhaps you are reading too much into bug 468159, or it's a language thing. Thunderbird is never perfect, nor is TB bug management, and much less are bug reports, so we need to assume and accept a certain degree of fuzziness to keep moving. I honestly don't see fundamental mutually excluding differences between these two bugs, except that this one is more advanced in its analysis of causes, thanks to you.
(In reply to Thomas D. from comment #60) > WADA, I think it might be misleading and error-prone to assume that > everybody works with the same level and awareness of detail and precision as > you do. Even if so, we should analyze difference among following. - Original report(comment ZERO) by bug opener, with bug summay - Many "me too" comments If duping is made based on many "me too" comments without analysis of original report, without careful analysis of many "me too" comments, it means "hi-jacking of a bug". If without careful analysis of each "me too", it's similar to following. - Tb's crashe was reported to bug-A, and many "me too" were added. - Crisp bug-B of "Tb crashed, Tb shouldn't crash" was opened. - Close bug-A as dup of bug-B, because external symptom of "crash" is same. If duping to this bug, it should be done on each "me too" in bug 468159. - Original : report for Tb 2. - "me too" #1 : for Tb 10 - "me too" #2 : for Tb 11 - "me too" #3 : for Tb 12 If all "me too" is same problem as original of this bug or a problem found in this bug, I think "Close as INCOMPLETE, as done by bug 468159 comment #2 on 2009-03-26" is better because no response from bug opener and the report was for Tb 2.
(In reply to Thomas D. from comment #58) > Can you give some short general ideas/directions how these known problems > can be solved? If "image url which points image part of previous mail" is mandatory for mail composing, (a) locking of the required previous mail is needed. And, delete of the previous mail by any other operation, offset change of the previous mail by Compact, should be prohibited. If current "image url which points image part of previous mail" mechanism can be changed, a possible solution is (b) copy all required subpart data to temp file upon any Reply/Forward/Edit draft/Edit As New/Compose from template. Bug 485593 is this kind of request on "Edit As New". For IMAP draft case, bug 720646 should be resolved in order to avoid "delete of wrong previous draft" problem and "delete failure of previous draft" problem.
Bug 453196 comment #0 is "original is deleted" case. Setting dependency for ease of tracking.
Depends on: 453196
Component: Message Compose Window → Composition
OS: Windows 7 → All
Product: Thunderbird → MailNews Core
Hardware: x86_64 → All
Version: unspecified → 1.9.1 Branch
Hi, after jumping on the "me too" bandwagon from comment 31. After following advice from comment 45 (disabling auto-save) I've never had re-occurrence of the issue (over the last 2 months), whereas I used to easily get replication within a couple of days. No other changes were made to program settings (including mail settings).
Blocks: 791973
Nothing to do with auto-save (disabled). Nothing to do with meanwhile-deleted external references or other complicated scenarios. Hit CTRL-R, CTRL-ENTER - wham, bam - no editing necessary - boom: Attaching! Every single goddamn time. Our corporate signature has social network icons inlined, plus the company logo. EVERY SINGLE reply I must first scan and manually delete all inline images from all the signatures, otherwise as soon as I hit CTRL-ENTER/Send, it's "Attaching..." time, baby, and hanging in there forever. It's madness! This has never happened on my system before. It started when I changed employers. I use the same system & settings as before. I only swapped my HDD between company notebooks. So no changes in the TB installation, version or settings. Well, one change: added a new account. They do have a different version of Exchange here, whose IMAP4 provider I'm using in TB (now it's Exchange 5.5, I believe, before it was some recent version). It doesn't matter. MIME is MIME. HTML composition and handling of multipart messages should work OK or not work at all. TB's a basically IMAP-only MUA, how come such a massive bug is still present? It's not simply annoying detail, if I wasn't a UNIX-head for 17 years, I'd kick TB in the nuts with a run-up a long time ago. BUT, what can I do - I'm used to it, I'm not migrating all my accounts filters, settings, etc. to Evolution or other MUA. I'm certainly not going to install virtual XP for Outlook (which, I understand, has actually a decent IMAP and S/MIME support - as opposed to TB). With IMAP being basically THE ONE protocol for TB, I (as a programmer) can't believe this is happening after so many years of development. My 2 tips: 1) if you can parse it & render it, you should be able to pack it back up and flush 2) S/MIME is not just for proving identity and encryption. There's also a little attribute called "signing time", which is why many people use S/MIME in the first place. If you're stamping the envelopes, you should allow users to INSPECT the stamps. Neat envelope icon marking (in)valid signatures opens a detail dialog on click, but none of the signing details are there. Only sender certifiacate's details. Good luck, gotta go, sorry. Had a scathing post/letter vs. S/MIME in TB metaphor prepared, but the lavatory's calling... GOTTA RUN!
My sentiments exactly! Its enough to bring on a spontaneous case of the ****. I keep updating TB upon each new release but still no fix. A debilitating Bug.
Oh, I forgot to mention, I dont use IMAP, I use POP, so I dont think its is peculiar to IMAP as suggested above.
Still see it with thunderbird16 (or above)? The code looks to be around here: http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgSend.cpp#2620
I use both IMAP and POP, and have autosave disabled for at least two months. The problem never showed up again since then.
But I need Auto-save ON.
hobo jo, I agree with you and love to have autosave working again. My comment was just to reinforce the linkage between the autosave state and this problem. BTW, I forgot to bring in my installation details: Xubuntu 12.04 64, TB 16.0.1
(In reply to Magnus Melin from comment #69) > Still see it with thunderbird16 (or above)? > The code looks to be around here: > http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgSend. > cpp#2620 yes. win7 16.0.1 This bug has been bugging me for a long time. :|
Since it appears that the underlying cause for the attach operation to fail is that the offset information on the mailbox: URI becomes invalid when compacting the folder with the original message (imap: URIs should stay valid unless the message itself is deleted, my understanding is that its UID remains a constant even if intermediate messages are deleted), a possible solution might be to follow what Editor did in bug 609632 and to convert those URIs to data: ones containing a snapshot of the image at the time it is added to the message. Then, the reference can shift whichever way it wants, without disturbing the included images. However, from the prior discussion in this bug and the references to other bugs, this doesn't seem to be the only issue for the "Attaching..." hang, but it may solve at least a major part of it.
Version: 1.9.1 Branch → Trunk
My "Attaching..." issue was solved by turning off auto-save. Now with new version 17.0 the problem is occurring again, even with auto-save still turned off. Something new or something else is now going on. I have a user stuck on an older version of Thunderbird (one that doesn't have this issue) because she relies on auto-save heavily and wouldn't tolerate this issue constantly popping up if I turned it off. Now, it seems whether or not I turn it off doesn't matter. I'm afraid I may have to migrate her (and her huge store of email) to another email platform that is current, which would be a massive undertaking. I'm very disappointed that this issue hasn't been fixed. (Windows 7 Pro 32-bit, multiple POP3 accounts with multiple providers; no IMAP accounts)
Sorry, made an error in my specs - should be: Windows 7 Pro 64-bit, multiple POP3 accounts with multiple providers; no IMAP accounts)
> I'm very disappointed that this issue hasn't been fixed. +1 It's been three years now. This has been driving me nuts just today and is becoming a deal breaker.
I've opened bug 817245 for specific/re-producible cases of my comment #42, except for comment #18 case which is already reprted as bug 453196, for ease of problem anaysis with less confusions.
No longer blocks: 766495
To bug opener, all problem reporters in this bug, future "me too" comment posters : As I wrote in bug 817245(needless to say, in original my comment #42), "Image location" of embed image in composing/editing HTML mail is shown like next, where nnn=Offset(local mail folder) or nnn=UID(IMAP mail folder). > mailbox:.../Inbox%3Ennn?part=1.2&filename=EmbedImage.jpg > mailbox:.../Drafts%3Ennn?part=1.2&filename=EmbedImage.jpg > imap://user-id@imap.gmail.com:993/fetch%3EUID%3E/INBOX%3Ennn?part=1.2&filename=EmbedImage.jpg > imap://user-id@imap.gmail.com:993/fetch%3EUID%3E/Drafts%3Ennn?part=1.2&filename=EmbedImage.jpg And, nnn=Offset(local mail folder) or nnn=UID(IMAP mail folder) of a mail is shown as "Order Received" column value by Tb. If you will see problem again, view "Image Location", check mail of Offset=nnn or UID=nnn which is pointed by the "Image Location" in mail folder which is pointed by the "Image Location", and check at least whether your problem is same issue as bug 453196/bug 817245 or not, please.
Blocks: 816901
(In reply to WADA from comment #79) I'm having the "attaching..." hanging issue all the time (it seems that it's getting even worse with each new Thunderbird version). I checked the offsets as you mentioned: - Offset of original message unchanged: I've checked the offset of the original message (I added the column "Order received" in the Inbox folder view and checked its value which is the offset) before and after the bug occurred (that is when I was still able to save the draft message and after when I was getting the bug when trying to save): the offset of the original message did not change (its value remained 781018687). So my issue does not fall in (case 2) of your comment #42. - no IMAP: I'm using POP, not IMAP, so my issue does not fall into (case 1) of your comment #42. - Offset of draft changed: I also checked the offset of the draft message ("order received" value) and this value is changing because it's changing each time I save the draft message, however I do not compact the folder so it does not change because of compacting, so my issue does not fall into (case 3) of your comment #42. As a conclusion, my "attaching..." hanging issue with embedded image is not the same as in your comment #42. I have Windows7 and Thunderbird 17.0. However I wanted to check the "Image location" but I didn't understand in your comment how I can find the "Image location", could you explain how to find it?
Depends on: 817245
No longer depends on: 453196
(In reply to François R-Champigneul from comment #80) > how I can find the "Image location"? At HTML mode composition window, select a image by single click, double click the image or Format/Image Properties.
(In reply to François R-Champigneul from comment #80) > - no IMAP: I'm using POP, not IMAP, (snip) > I do not compact the folder (snip) If so, file size of Drafts increases forever, because file size limitation due to 32bits integer use(signed or unsigned) for Offset value is already removed by 64bits integer use(perhaps signed) for Offset value. At following internal URL processing, > mailbox:.../Drafts%3Ennn?part=1.2&filename=EmbedImage.jpg > == mailbox:.../Drafts>nnn?part=1.2&filename=EmbedImage.jpg Tb may use 32bits integer(signed or unsigned) for value of "nnn"(MsgKey==Offset if local mail folder, except in special situation) in embed image processing. If so, "nnn" larger than 2GB-1 or 4GB-1 may cause problem. Such case?
Original report of this bug(commnt #0) and many of problem reports in this bug on "Attaching..." phenomenon sounds to fall in one of bug 453196 for specific case, specific bugs pointed in bug 453196, and bug 817245 for specific case. "Same as such bug or different from such bug" is very easily known by checking "Image location" and "Order Received column value". Check "Image location" and "Order Received column value" before adding comment about your "Attaching..." problem, please. However, apparently different cases are involved in this bug. "HTML mail with embed image" and "Attaching..." is same. Original mail of reply/forward/edit-draft is not deleted, so it is not same as bug 453196. And, "Offset change by Compact" is never relevant to the problem. Type-A : IMAP, so "Offset change by Compact" can not happen. It can't be same as bug 817245 on local mail folder. ( comment #44, comment #47 ) Type-B : Auto-compact is disabled, and manual compact is not executed, so "Offset change by Compact" won't occur, bug 817245 is irrelevant. ( comment #80, comment #82 ) Type-C : Not Type-A/Type-B. Removing symptom of bug 453196 and bug 817245 from bug summary, for such outstanding Type-A/B cases, to avoid misleading, and adding pointer to those bugs in bug summary, to rule out already known specific cases from this bug.
Flags: needinfo?
Keywords: reproducible
Summary: Sending reply to (or forward inline of) existing message with inline images fails with error message: "attaching..." (If replied/forwarded/previous-draft mail is deleted or its offset is altered while mail composition, Send/Save can't find the mail) → Sending reply to (or forward inline of) existing message with inline images fails with error message: "attaching..." (this bug is kept for other cases than bug 453196, bugs pointed in bug 453196, and bug 817245)
"inline image" can mean "image file attachment displayed in inline". So changing "inline image" in bug summary to "embed image" which is usually used for "<img src="cid:cid-URL"> and image part with Content-Id: <cid-URL>.
Flags: needinfo?
Summary: Sending reply to (or forward inline of) existing message with inline images fails with error message: "attaching..." (this bug is kept for other cases than bug 453196, bugs pointed in bug 453196, and bug 817245) → Sending reply to (or forward inline of) existing HTML message with embed images fails with never-ending error message: "attaching..." (this bug is kept for other cases than bug 453196, bugs pointed in bug 453196, and bug 817245)
For IMAP Drafts case. If Gmail IMAP with auto-expunging=Enabled, never-ending "Attaching..." can easily be reproduced by following simple test, even with IMAP delete model="Just mark it as deleted". (1) A draft mail with embed image in IMAP Drafts folder ( call UID=(NN) ) (2) Edit the draft mail => window-1 is opened. Current UID=(NN) (3) Edit the draft mail again => window-2 is opened. Current UID=(NN) (4) At window-1, Save As Draft, without change, or with change => Read image data from UID=(NN), append new draft mail (=> Gmail IMAP assigns new UID=(NN+1). ) ( if Gmails considers same mail data as existent draft, ) ( Gmail automatically removes UID=(NN) from Drafts folder.) uid (NN) store flag \Deleted (=> Gmail automatically removes UID=(NN) from Drafts folder,) ( if auto-expunging=Enabled. ) So, in any case, mail of UID=(NN) is permanently removed from Drafts, then Tb can't see mail of UID=(NN) any more even with "Just mark it as deleted". (5) At window-2, Save As Draft Try to read mail of UID=(NN) for embed image data => Because mail of UID=(NN) doesn't exist, "Attaching..." occurs. Above may occur even with non-Gmail IMAP server if IMAP delete model is "Move to trash" or "Remove immediately", because "UID stored \Deleted flag" is immediately removed from MsgDB of Tb. If similar thing happens between "read UID=NN/delete UID=NN after Send" and "read UID=NN/appnd to UID=NN+1/delete UID=NN by auto-save", similar never-ending "Attaching..." may occur. If your case is IMAP case, and if your case is not same as bug 453196, get IMAP log and attach IMAP log to bug after remove/replace private data, please.
I'm experiencing the same problem. Just want to add that it's NOT specific to IMAP - can happen with any account. There seems to be no consistency. This error is only caused by the existing attachments in the message you're replying to. The solution is to delete them - which in most cases isn't an issue. New attachments don't cause the problem and don't have to be deleted. This problem started only in recent versions - from around v14. [multiple Macs and system versions]
(In reply to Leo from comment #94) > This problem started only in recent versions - from around v14. No. Its been a problem since Thunderbird/3.1 But nobody with the power to fix it, has the inclination to do so.
While I have no insight to offer regarding a proper fix, I do have a workaround that I derived by reading the developers' comments. If this issue occurs, click "Cancel" on the stuck dialog and go File -> Save As -> Draft, and attempt to resend the message. This measure seems to work without fail.
(In reply to ben from comment #96) > If this issue occurs, click "Cancel" on the stuck dialog and go File -> Save > As -> Draft, and attempt to resend the message. This measure seems to work without fail. If phenomenon of bug 453196 or bug 817245, it's impossible to recover because referred mail doesn't exist any more when "File->Save As->Draft" is requested after "Cancel". May be problem like next I already pointed in commen #47: 　　Previous draft version=(n) Auto-save is invoked Start creation of draft version=(n+1) Sending starts with referring version=(n) draft version=(n+1) is created Delete previous version=(n) Current version=(n+1) Try to read data in version=(n) => Because version=(n) is already deleted endless "Attaching..." Cancel sending Save As draft => Because latest version=(n+1) exists, newest version=(n+2) can be created Biggest problem of this bug: No one provides required data for problem determination. Always adding report of 'endless "Attaching..." happened in my environment too' only. Because it's already known that many of endless "Attaching..." phenonomenon occurs on embed image, it's already known that "image location in composing mail" is one of most important data. And, "how to check image location" is already written at many places in relevant bugs including this bug. However...
(In reply to WADA from comment #97) > Biggest problem of this bug: No one provides required data for problem > determination. Always adding report of 'endless "Attaching..." happened in > my environment too' only. This problem happens to me almost daily. Please let me know exactly what information you need and I'll try my best to get it to you.
(In reply to Mike Robinson from comment #98) Already known things. (i) comment #18 == bug 453196 As found by comment #18 of this bug, which is first and only one report of clear/crisp "steps to reproduce" in this bug, endless "Attaching..." phenomenon occurs when (a) embed image is used in HTML mail, and (b) referred mail by Forward(or by Edit draft) which holds image data is removed. This simplest case is bug 453196, and culprit of (b) is Tb user who are composing the mail in ths case. (ii) bug 817245 When bug 817245, culprit of (b) is usually "Auto-Compact". And, in this case, "data in other mail" can be silently used by Tb instead of that endless "Attaching..." happens. (iii) Suspected phenomenon In suspected phenomenon of commen #97(== commen #47), culprit of (b) is Auto-Save. Minimum data required for problem isolation is; - IMAP or POP3, Auto-Compact is used or nor, Auto-save is used or not, Draft is relevant or not. - What happend. - Endless "Attaching..." - Image of diferent mail or draft is used - Non image data of diferent mail or draft is used for image - Nothing is written as data for embed image part - Image location of composing mail when problem occurs. As written in many places, image's property is very easily shown. "Double click of image" is an simplest operation for it. - Status of referred mail by image location in composing mail. Other mail is referred by messageKey in image location. messageKey value of referred mail is shown at "Order Received" column. If these are clear, which of (i), (ii), or {(iii) or other} is easily known. And, following is helpfull. - Analysis of your problem by yourself, after summarizing your problem. messageKey value of "referred mail by image location in composing mail" is changed while mail is being composed, including "messageKey disappears by mail delete", by you, by Auto-Compact, by Auto-Save, or by someone else.
Needless to say, because (i) bug 453196 and (ii) bug 817245(and bug 766495, bug 799450) is 100% reproducible, additional "Me too" on (i) and (ii) is useless, rather disturbing.
Hmm... Can i say, "Me Still"! This report started back in 2009! It would be nice if someone actually FIXed these bugs since its so easy to repeat on the user side.
(In reply to hobo jo from comment #95) > No. Its been a problem since Thunderbird/3.1 (In reply to hobo jo from comment #101) > This report started back in 2009! I can't think so. bug 453196 was opened on 2008-09-01. So, "endless Attaching..." surely began to occur at least in 2008. If same thing as bug 453196 occurs on "Forwarded as attachment" mail, phenomenon is altered to "data of image part under rfc822/part is null in sent mail or saved draft". I think "mechaism to access other mail's data in composing mail" is not so largely changed from initial of Tb. And, Compact is a feature since initial of Tb. I guess problem of "null data part in sent mail" in some conditions was morphed to phenomenon of "endless Attching..." in 2008, if users began to notice phenomenon of bug 453196 in 2008. So, I guess problem since initial of Tb. "100% Reproducible" doesn't always mean "resolving is prety easy". And, because root cause is in design, it's hard to resolve compared with "simple mistake in coding which produces different behavior from design". Reason why priority of bug 453196 was low. - Cause of that bug is user himself; delete of forwarded mail was done by user, even though user is forwarding mail. - "Data loss" is image part only, so it's not so significant in many many cases. Reason why priority of bug 817245 is not so high. - "Data loss" is image part only in the last composition. And, image data is also recoverable from old version of draft mail which was moved to different offset by Compact. So it's not so significant in many cases. It's merely petty annoying for users who keep environment where phenomenon of bug 817245 occurs pretty frequenly. However, we unfortunately discovered symptom of bug 799450. There is no consitent way to protect user from the problem, although "Disabling Auto-Compact" is usually an effective workaround of bug 799450(and his friends). Anyway, problem of bug 453196 and bug 817245 is already moved from this bug to bug 453196 and bug 817245. Read those bugs well, please, instead of adding comments to this bug merely by "you also saw endless Attching...". This bug is kept for "endless Attaching..." phenomena what is surely different from bug 453196 and bug 817245. As seen in some comments in this bug, we can't deny existence of such problem. Please focus on it　in this bug.
What ?
(In reply to hobo jo from comment #103) > What ? My asking is; please don't add comments which is merely a complaint what is absolutely useless for problem determination in this bug and fixing bug of Tb, please.
See Also: → 790230
Added two more possible duplicates to see-also, Bug 790230 and Bug 591181.
See Also: → 591181
Similar (inline images fail), but not necessarily a dupe: see also bug 764197
See Also: → 764197
Confirmed: turning off Auto-Save fixed this for me.
Summary: Sending reply to (or forward inline of) existing HTML message with embed images fails with never-ending error message: "attaching..." (this bug is kept for other cases than bug 453196, bugs pointed in bug 453196, and bug 817245) → Sending reply to (or forward inline of) existing HTML message with embed images fails with never-ending error message: "attaching..."
Whiteboard: [gs] → [gs] this bug is kept for other cases than bug 453196, bugs pointed in bug 453196, and bug 817245
I re-enabled Auto Save for Drafts and I haven't seen this problem re-appear for several months. Unfortunately, I don't know with which TB release the problem ceased; maybe 24.0.0? I'm on 24.4.0 now. It would be ideal to know whether somebody actually attempted and committed a fix that targeted this problem, explicitly, or whether some seemingly-unrelated change fixed this bug, too. I'm curious to know whether this problem seems to have ceased recently for others...
Perhaps your specific use case no longer suffers from this bug - but the bug is certainly still there. :) Less than a week ago (on 24.4.0), I had to spend quite a while before being able to get my message to send. If I remember correctly, some images were referencing to something inaccessible like an imap: address or something, and I'm assuming Thunderbird doesn't manage to send the email because it can't find the image to attach it. Wouldn't it be great if Thunderbird simply alerted us of that then! Something similar to the 'did you forget your attachment' message. It could say, perhaps after a timeout, "Can't find the image [address]! Send the email without attaching it?".
Problem ceased for me too... Can't figure out when though. (In reply to ben from comment #110) > I re-enabled Auto Save for Drafts and I haven't seen this problem re-appear > for several months. Unfortunately, I don't know with which TB release the > problem ceased; maybe 24.0.0? I'm on 24.4.0 now. > > It would be ideal to know whether somebody actually attempted and committed > a fix that targeted this problem, explicitly, or whether some > seemingly-unrelated change fixed this bug, too. > > I'm curious to know whether this problem seems to have ceased recently for > others...
Sorry, just realized I have autosave disabled. I'll re-enable it and see what happens. But I guess Joris is right. (In reply to Juan Cruz Varela from comment #112) > Problem ceased for me too... Can't figure out when though. > > (In reply to ben from comment #110) > > I re-enabled Auto Save for Drafts and I haven't seen this problem re-appear > > for several months. Unfortunately, I don't know with which TB release the > > problem ceased; maybe 24.0.0? I'm on 24.4.0 now. > > > > It would be ideal to know whether somebody actually attempted and committed > > a fix that targeted this problem, explicitly, or whether some > > seemingly-unrelated change fixed this bug, too. > > > > I'm curious to know whether this problem seems to have ceased recently for > > others...
(In reply to ben from comment #110) > I re-enabled Auto Save for Drafts and I haven't seen this problem re-appear > for several months. Unfortunately, I don't know with which TB release the > problem ceased; maybe 24.0.0? I'm on 24.4.0 now. > > It would be ideal to know whether somebody actually attempted and committed > a fix that targeted this problem, explicitly, or whether some > seemingly-unrelated change fixed this bug, too. > > I'm curious to know whether this problem seems to have ceased recently for > others... Ben & others, I appreciate your initiative to collect user feedback on this bug. Active users can help shape a better product. However, let's also ensure to work productively here and avoid too many distractions. Myself being one of TB's main volunteer contributors mostly in QA and UX, let me try and set out the nature of this bug. As hinted in Whiteboard field of this bug, this bug is to collect bugs which report the same symptom ("Attaching..." endless spin), but whose causes have not been verified yet. On the other hand, we have (at least) two verified causes for this bug: Bug 453196 Embedded image URL points to another msg and that other msg is deleted before saving/sending (so picture can't be found any more) Bug 817245 Embedded image URL points to another msg (via MessageKey of that msg) and (Auto-)Compacting of folders changes the MessageKey of that other msg, so picture can't be found any more when sending/saving. FTR: This bug can never be "worksforme" until both bug 453196 and bug 817245 have been fixed first (hence this bug "depends on" those two bugs). I personally think that most users affected by the symptoms of this bug 532395 are actually seeing one of these two bugs, iow if we'd manage to fix those two, there's a good chance that most, if not all of the problems reported here will go away. In view of that, the following type of comments, albeit provided with best intentions, are not very useful and thus discouraged (unwanted) on this bug: "I no longer see this bug, it's gone" (No, it isn't! See next line for details.) "I still see this bug" (Yes, we all know this bug is unfixed at least until bug Bug 453196 and Bug 817245 are fixed, and further general confirmations do not help to solve it; only details about new causes or details about how to fix this might help). If you just want to register that you're affected by this bug, consider "voting" for this bug (near the Importance field at the top). High numbers of votes are still a good and useful indication that this bug is important to users. However, for a number of reasons, even high numbers of votes unfortunately do not always translate into fast fixes (more on the manpower problem below). It's easy to think those bugs are gone when you no longer see them; however, especially bug 817245 can still affect you any time as long as auto-compaction is on (and manual compaction, too, if you happen to have such drafts around), but it obviously requires some co-incidence so it will happen to you sometimes, but not always (and many users are not aware of auto-compacting, so they might wrongly attribute this to other causes). There might be variants of Bug 453196, too: Maybe the original msg from which the images were embedded into your composition isn't deleted, but just disconnected or otherwise not available for some reason. The net effect will be the same, and such variants will most likely be fixed by Bug 453196. All of these bugs are part of a more general design problem that things which you see in your composition (and rightly expect them to actually BE there) have actually NOT yet been physically transferred into the control range of your composition, but are just referenced from all sorts of uncontrollable sources which can dissapear by deletion, moving, renaming, updating etc. I have filed this as Meta bug 877159 (alias: attach-paradigm-fail). This design problem is widespread but not easy to understand and not easy to fix; I'm not even sure to what extent this has been acknowledged as a general design problem by developers; but I've done my best to present the problem and evidence from related bugs to support that analysis, and other well-known bug triagers have come to the same conclusion: In a nutshell, all things which are seen in your composition should be copied immediately so that they are in the exclusive control range of your composition, which would solve most if not all of these bugs. Things might be more tricky with IMAP where everything needs to be mirrored on the server, too, not just your local machine. In case you're wondering why it takes so long to fix identified bugs, pls be aware that Mozilla has de-funded TB so development of TB is now done by volunteers (including some Mozilla employees dedicating their spare time). Iow, now more than ever, TB development is faced with a shortage of manpower. More so because unfortunately, we have thousands of other bugs around, and enough other bugs are just as bad or worse than this one. Although this cluster is actually quite serious and reported frequently, so I personally would recommend a concerted effort to get these out of the way, perhaps starting from here: Bug 854798 - Compacting Berkeley Mbox file changes messageKey (to new MsgOffset after compact), causing dataloss/privacy problems like bug 817245 due to current design problem of MsgKey=MsgOffset (for Berkeley Mbox files) Bug 854798, from my pov, is at the centre of many bad bugs including many instances of this bug here. However, Bug 854798 Comment 21 by Aceman suggests that Bug 854798 as filed might even be wontfix, and solutions should better start from bug 799450 or bug 817245 (which probably assumes a certain approach for fixing those, which might be another debate). You see, it's not easy, as we're digging deeply into TB code internals here and it involves far-reaching design decisions and loads of delicate work. If you are a coder and willing to assist, most welcome! :)
Whiteboard: [gs] this bug is kept for other cases than bug 453196, bugs pointed in bug 453196, and bug 817245 → [gs] [Read Comment 114 before commenting] [this bug collects cases other than bug 453196, bugs pointed in bug 453196, and bug 817245]
(In reply to Thomas D. from comment #114) For more details on the technical analysis side of these bugs, or how to add useful information for us to find unidentified causes apart from known causes, pls read the comments written by WADA, who is also one of the main TB QA contributors, e.g. comment 99 and comment 102.
As wrote in bug 977102 comment #2 by someone, this bug is cesspool for bugs exposing that error msg without any valuable information for problem determination or problem analysis by developers. (a) If a user can read and understand bugs for "100% reproducible" cases, and (b) if a user actually observed phenomenon of his problem carefully, I believe any user can do one of next. (i) His problem is same as one of already known "100% reproducible" bugs, so add comment to other proper bug if required, instead of adding comment to cesspool. (ii) His problem is absolutely different from already known "100% reproducible" bugs, so add comment to this cesspool with clear description about his new case in this bug. Report of "Attaching... happened" only, without clear description nor required data for problem analysis, even after some "100% reproducible" cases were found in this bug, is sure evidence that a user won't do (a) nor (b). This bug is pretty useful to count # of "Attaching..." phenomenon which actually happened in user's environment. It's one of many reasons why this bug is kept open. Even if reading Whiteboard: field of a bug at B.M.O is slightly hard, following is already written in Whiteboard for long time. > Whiteboard : > [gs] this bug is kept for other cases than bug 453196, bugs pointed in bug 453196, and bug 817245 I don't think any future problem analysis will be needed in this cesspool.
this bug still exists but i come across it very rarely. The trigger is the sender having a graphic in their message footer, to resolve it i delete the graphic and then the email sends fine. this is pop3 here , although i doubt it has to do with any particular mail retrieval type. The trigger for it may be due to the way the sender mail client does its HTML as it seems to be an issue that derives from Microsoft based clients. the reduction in the issue maybe due to the senders upgrading their client software to versions that do not trigger this , thereby "fixing" the issue externally.. my 2 pence worth on this oldie :)
forgot to mention, this is when REPLYING to an email with a footer.
(In reply to bill.lewis from comment #117) > The trigger is the sender having a graphic in their message footer, (snip) This indicates "Forward already receved HTML mail by HTML mail" case. If so, and if your problem is same as Bug 854798, culprit is usually never mail sender. Culprit is usually always Thunderbird. Embed image in HTML mail is sent format like next; A main in an local mail folder of Tb: This mail is pointed by mailbox:///C:/ ... /Mail/pop.domain.com/Inbox?number=12345 Content-Type: multipart/related Content-Type: text/html <img src="cid:ID_of_embed_image"> Content-Type: image/jpeg Content-Transfer-Encoding: base64; filename="abc.jpg" Content-ID: <ID_of_embed_image> base64 encodedd image data is contained in this part This image part is pointed by next URL like one. mailbox:///C:/ ... /Mail/pop.domain.com/Inbox?number=12345,&part=1.2&filename=abc.jpg When this embed image in an HTML mail is used in reply/forward/""edit as new, and if composed mail is saved as draft by Tb, draft mail like following is generated by Tb. This draft mail is pointed by mailbox:///C:/ ... /Mail/pop.domain.com/Drafts?number=34567 Content-Type: multipart/related Content-Type: text/html <img src="cid:New_ID_of_embed_image_in_draft"> Content-Type: image/jpeg Content-Transfer-Encoding: base64; filename="pqr.jpg" Content-ID: <New_ID_of_embed_image_in_draft> base64 encodedd image data is contained in this part This image part is pointed by next URL like one. mailbox:///C:/ ... /Mail/pop.domain.com/Drafts?number=34567,&part=1.2&filename=pqr.jpg ?number=opqrstu part is "Offset in a local mail folder file" in Tb. If Compact happens on mail folder where the pointed mail(original or previous version of draft), "Offset of the pointed mail in local mail folder file" is changed by Compact. Because Tb can't find "mail at Offset=opqrstu" after Compact, Tb fails to find image data. If this occurs on "Embed image in HTML mail", phenomenon of "Endless Attaching..." occurs. Above is essential phenomenon of Bug 854798. Nothing bad in original HTML mail is involved in above phenomenon. Anyhing bsd/wrong is in Thunderbird, if your problem is same as Bug 854798. As written at many places in already pointed bugs, all of above can be observed merely by; 1. Show "Order Received" column(if local mal folder, value is Offset in file). 2. Show "Image Location" of image in composing mail (Offset is shown as ?number=opqrstu). > The trigger for it may be due to the way the sender mail client does its HTML > as it seems to be an issue that derives from Microsoft based clients. What kind of "badness of MS based client" is involved in your case? Even though MS based clients frequently ignores mail related RFCs, IIUC, as for problem of Bug 854798, there is nothing bad/wrong of MS based clients.
It would take me forever to read through all the comments and the few replies from mozilla about this bug but I just found a way around it. C & P what you want in the email and paste it to a word document. save it. close down firefox and thunderbird. run Ccleaner. Open thunderbird, open the email you want to reply to and paste your reply and send. mozilla stuff is a pain in the padded ass sometimes. They seem to think everyone who uses their software is a computer genius. Some of are not and don't have the time to **** around all day trying to find a fix when it should be part of an update that gets downloaded to my computer anyway. Get your heads out of your asses people we don't have time for this.
Thunderbird Developers - We need your help! First, let me apologies for all of those that like to send hate mail in this form. You all work very hard, are extremely competent, and do an unbelievable amount of work asking for nothing, or very little, in return. Many of us, especially those that have used Thunderbird for better part of the last two decades, are extremely grateful for your tireless efforts. This bug is still a issue in version 31.1.2. It has been a problem for a very log time. It is easy to duplicate on any machine, any OS, POP or IMAP, and has occurred in at least the last 20 versions of Thunderbird. Issue: When forwarding messages that have icons or logos with links in them (usually a company logo after a persons name), the email will hang upon sending, showing a screen that says Status: Attaching... and showing a Progress Bar that continues to show activity. The only way out is to click the Canel button, at which time the send abandons without action. Workaround 1: Delete Icons or logo links from original (forwarded email). Again, usually all it takes is to delete the company logo after the persons name and the email will send just fine. Workaround 2: As mentioned before in other posts, Cut the Icons or logos link from original (forwarded email), paste into another application. Save the Icon or logo link from that application as a jgp file. Go back to Thunderbird and insert the jpg where you cut the original out (resizing is sometimes needed to make them match). Workaround 3: Go to Google Images. Find the logo that was in the original (forwarded email), save it as a jpg file. Delete the one that is in the forwarded email and insert the one you found and saved from google. I'm guessing that the problem has something to do with the mechanism that is invoked when you forward an email in Thunderbird and that the "sending" mechanism itself is not the problem. Somewhere during the forwarding process, the original logo-link associated with the original email is somehow broken when it is moved to the forwarding email. Please don't give up on solving this problem. Many of us would very much like to continue using Thunderbird. Craig Lassen Basic issue is
Fwiw, I have found that often (but definitely not every time), simply clicking 'Cancel', then clicking 'Send' again will result in the message being sent.
In response to Charles email... I have also see the behavior that Charles described (pressing the "send" multiple times will eventually send out the email). I believe this to be a different issue. When I was/am able to click the "send" a second time to get the email to go out, I have noticed over the years a fairly tight correlation of this behavior to other processes, updates, bandwidth issues, etc. Please understand that I am not attempting to minimizing what Charles and others have reported, I just want to keep the issues separate so that they can be diagnosed individually and not collectively. If there are multiple issues involved, we must separate them as best we can in order to affect a solution for each. The issues I discussed in my earlier post, and as reflected by others, is uniquely definable and can be duplicated at will. There are no intermittent or random components. The reason that some emails with Logo's send, and other don't, I believe, has to do with how the original Logo, in the original email was fashioned, although I am no expert on email Logos or images. If the Logo is problematical and prevents send, it will always prevent send, no matter how many times it is forwarded or sending is reattempted. I have been able to duplicate this problem on multiple OS's and multiple machines as I mentioned earlier including, most recently, both Windows 7 and 8.1. I have only tested it with POP but my fellow engineers tell me that this behavior can also be seen in IMAP as well. Lastly, the work-around's always works as long as the original offending logo can be linked back-up with the original email so that a jpg can be saved and reinserted to replace the offending Logo or other image. This is why I believe this issue is solvable. I hope that helps. Craig
(In reply to Craig Lassen from comment #121) I can confirm the problem, for both, forwarding and replying. I'm using Workaround 1: Delete Icons. Name Thunderbird Version 31.1.2 User Agent Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 Profile Directory (Local drive) Application Build ID 20140924103150
I have a way to reproduce it exactly: 1. Receive an HTML email with logos / images 2. Click on reply (or forward), but leave the compose window opened 3. Go back to the main window, and delete or even just move the email to another folder. 4. Go back on the compose window, type some text - or not - and press send. The compose window display "Attaching..." for ever. I suggest that as soon as you click reply, the compose window should copy the external resources in it's own cache. I am sure this would just fix the problem.
Same problem here (In reply to Craig Lassen from comment #121) I'm using Workaround 1: Delete Icons. Name Thunderbird Version 31.1.1 (but the problem exists a long time before)
Same problem. My workaround is to close the message, saving it in the drafts folder. From there you can open the message and send it without problems. I'd love to not having to do this. Cheers.
+1
I've started getting hit by this bug over the last couple of months leading to frustrating issues where emails I believe I've sent are stuck in the background processing and hidden by other windows over top. Because there are no other indications that something is wrong and thunderbird is otherwise working correctly there have been several occurrences where I discover emails I believed I sent days earlier are still stuck in limbo. :( As mentioned above, deleting embedded images in the original email before sending seems to fix it. Saving to draft and then editing again to send sometimes, but not always works. It's hard to believe that this bug has been around since 2008 and is still causing issues :(
I am struggling with this bug almost every day on Win7 TB 31.4.0. As soon as i leave a message with something embedded open for too long, sending hangs with "attaching", and the only remedy is to find the original message, reply again, copy my reply over - and it works. Plse, could somebody look into this.
A critical bug not fixed after 6 (SIX) years? Last time I use Thunderbird or recommend it.
Please solve this problem. We are in the 31th release, and the problem remains. It's the only "but" I have found to this EXCELENT mail software. Or PLEASE, at least show us how to solve it until you find a solution to it. Thank you in advance for your response.
There is a way around it, remove footer images from the email you are replying to. It seems the code thinks the image in the original email is an attachment but cannot find it . Either that or if it saves the original image to disk, it doesn't know how to find it when you go to send a reply. It seems a fairly simple bug but sadly i am not a coding expert so unable to do much directly here to help. I know i reported it some years ago now but it is livable with in my environment here and doesn't occur to often now, which also makes me think it is a quirk in the way certain MTA's craft emails in the first place and perhaps that MTA is falling out of use or has fixed their bug in more recent releases. microsoft? *cough* Bill
(In reply to bill.lewis from comment #134) > There is a way around it, remove footer images from the email you are > replying to. I think that it goes away if you disable automatic draft saving too. The problem only occurs after mailnews saves at least one draft because somehow in saving the draft the linkage to the original embedded image is lost(?). Sorry, replying mostly out of memory here/untested. If your computer and mailnews is stable enough and/or you always write short emails, perhaps give a try at turning off automatic draft saving and report if that helps? > I know i reported it some years ago now but it is livable with in my > environment here and doesn't occur to often now, which also makes me think > it is a quirk in the way certain MTA's craft emails in the first place and > perhaps that MTA is falling out of use or has fixed their bug in more recent > releases. Maybe it is more common for people to host/link images than embed them nowadays? I myself like the idea of embedded images because then the email can be reconstructed even if a hosted image’s source disappears. Also, the “fault” should lie in a MUA—the mail access software that is assembling the email in the first place—, not an MTA (which shouldn’t be modifying messages)…
If you reply to an e-mail that has an in-line graphic (typically a company logo in the other person's signature), and the window sits open long enough for Thunderbird to save a draft, when you finally do hit send, it hangs on "Attaching...". POP/IMAP no difference. Windows XP x86 / 7 x86/x64 no difference. I have many computers in the office and they all experience the same bug.
Never ending story?
I'm not sure if any code changes have been made to try and move this bug around but I've learnt to just remove inline attachments from replies/forwards if a message hangs up when I'm trying to send. This always gets around the issue. I've long suspected that this problem is all down to the management of temporary files and I've just observed a devastating side effect: I received an e-mail with an inline attachment (a screenshot) and when I replied to the e-mail Thunderbird switched the inline image of the screenshot with another image I had sent previously in a totally different e-mail thread. In fact I didn't realise that the problem had occured until I received a reply to my reply, noticed the image substitution, went back to look in my Sent folder and discovered that Thunderbird (31.5.0 running on Windows 7 Professional 64-bit) had switched the inline image in my reply. I'm sure everyone will realise the potentially nightmarish security implications of this problem. I'm happy to cooperate with developers to try and track down this issue but the nature of the e-mails I'm referring to mean that I can't just forward them on for public perusal. Perhaps others could check their sent items to see if they can locate other examples of inline image swapping? This issue now surely demands very urgent attention.
(In reply to richard from comment #138) > I'm not sure if any code changes have been made to try and move this bug > around but I've learnt to just remove inline attachments from > replies/forwards if a message hangs up when I'm trying to send. This always > gets around the issue. > > I've long suspected that this problem is all down to the management of > temporary files and I've just observed a devastating side effect: > > I received an e-mail with an inline attachment (a screenshot) and when I > replied to the e-mail Thunderbird switched the inline image of the > screenshot with another image I had sent previously in a totally different > e-mail thread. > > In fact I didn't realise that the problem had occured until I received a > reply to my reply, noticed the image substitution, went back to look in my > Sent folder and discovered that Thunderbird (31.5.0 running on Windows 7 > Professional 64-bit) had switched the inline image in my reply. > > I'm sure everyone will realise the potentially nightmarish security > implications of this problem. Indeed. Bug 766495 for swapped images (privacy-violation), Bug 799450 for swapped text (privacy-violation). Both might be fixed for the upcoming release of TB38, as we have fixed what seems to cause them: Bug 854798 Compacting changes msg key... (which then spoiled the existing references in drafts, something like that).
Thanks Thomas. I subsequently filed this as a new bug under 1143294 but I can see that all these issues are indeed linked and hopefully the root cause has been identified. I can only add that this issue appears to be consistent with old partial autosaves appearing in the drafts folder - I'm pretty sure this happens after Thunderbird is restarted. I shall spend a little more time trying to recreate the issue in TB31 but remain hopefully the underlying issue has been fixed.
Hi! I was experiencing the same problem with "attaching error" and ran through several suggestions: 1- restart thunderbird (RESULT: same error) 2- cut content, save as blank draft, paste email, send (RESULT: same error) 3- remove attachment and try sending without (RESULT: same error) 4- try sending from various thunderbird accounts I have (RESULT: same error) 5- cutting and pasting the reply into a new message with no attachment (RESULT: same error) What I discovered was that the person I was responding to had an image in their signature. Each time it would produce a broken image. SOLUTION: I deleted the image from the signature and sent the original message I intended (complete with my attachment). **Note for #2 and #5: I think that if you tried these options and had success my guess is that there was previously a broken image somewhere in the email body that un-broke on pasting the email. Hope this helps.
This bug persists for years, and can be reproduced easily. It is not acceptable for me to find and delete all logo images in every incoming email before clicking the send button, it takes time especially for a long email thread. It is the most annoying bug which, if not fixed asap, will drive many TB users crazy...
Version 38 potentially has a fix. If you wish, you can test the beta from http://www.mozilla.org/en-US/thunderbird/channel/ and leave a breif comment as to whether the behavior is changed
(In reply to robert.grizilo from comment #136) > If you reply to an e-mail that has an in-line graphic (typically a company > logo in the other person's signature), and the window sits open long enough > for Thunderbird to save a draft, when you finally do hit send, it hangs on > "Attaching...". > > POP/IMAP no difference. Windows XP x86 / 7 x86/x64 no difference. I have > many computers in the office and they all experience the same bug. It may be worth noting that, in addition to hanging with the "Attaching..." message when trying to send the email, the "Attaching...." messsage also appears in the 'Status Bar' in the bottom left of the window. Whenever I have seen the "Attaching..." message stuck in the bottom left of my draft window, I also get the perpetual "Attaching..." message when I try to send the email. Also, I have trouble exiting the draft window in this state if I tell it to save the draft. I end up having to force close the draft. My current workaround is this: 1. Copy what I have written so far. 2. Close the draft window. 3. Select the "Don't Save" option in the pop-up dialog 4. Select Forward/Reply/Reply-all again 5. Paste my message from the lost draft. 6. Send Note: This becomes much more tedious if you are trying to reply inline.
A simple workaround (yes, I know it is a workaround, but it works) is to simply highlight only the relevant text that you want to include in the quoted text in your reply, excluding any/all images that might be a problem (these are almost always in email signatures anyway so are not important), then when you do reply, only the highlighted text is included in the quoted text... That said, I understand there are times when you might want to include the entire thread, and I'm looking forward to a fix, if 38 really does squash it... @Thomas - you say t his is fixed, but this bug is not marked as fixed. What bug contains the discussion that resulted in code changes to fix this? I'd like to go read more about it. Thanks!
(In reply to Charles from comment #145) > @Thomas - you say t his is fixed, but this bug is not marked as fixed. What > bug contains the discussion that resulted in code changes to fix this? I'd > like to go read more about it. Many occurences of this bug should be fixed in TB 38 by bug 854798. Probably all the reply/forward scenarios are fixed, because we compacting will no longer break the links to the images in drafts. The delete/move scenarios are not yet fixed, that's bug 453196.
This issue is fixed by v38.0 Beta3, tested on Windows.
The bug persists in TB 38.0.5 In my case I found that it was some pasted html that caused the issue. I pasted a table from a website into a html email. attached the file and clicked send. once the issue occurred it couldn't be cleared the email could not be saved even if I deleted the attachment. After trying several alternatives I was able to send the email and attachment by copying the text from the email and forcing the email to close (it would hang if i tried to save it) Then paste the plain text into a new email, format it as required attach the file and send It immediately went. My assumption is some sort of invalid character was inserted into the email when pasting and the "Attaching" message is a red herring DC
To add to my post above. The pasted html did NOT contain an image, it was purely text in a table. The email I was replying to did contain an image. That image did not appear to cause any issues as the email was sent correctly after I removed the copy and pasted html table. The person I was responding to was a contact I have replied to many times.
For the record, this bug continues to exist in 38.0.6 too.
See Also: → 1185195
This happens really randomly for me, but mostly when I left an message open for editing for a long time, when I'm responding while checking the info I'm responding about. And it's aways the same file all the time. It's a file from an HTML signature common for everyone in my company, I took a look at the code and it seems to point to a web address. Maybe this happens when the file is temporally unavailable from the web address but I'm guessing Thunderbird shouldn't be doing that. In older versions the "Attaching pontilhado.jpg" message would pop up on the status bar at some point in time while my message was open for editing, and I knew I wouldn't be able to send that message anymore, now I think there aren't any more messages on the bottom bar but the message pop-up box when I ctrl-enter to send is still there, and the mail remains unsent.
Hello everybody, just to say that I experience - always - the same problem replying mail with "jpg" signature from sender. Workaround: delete signature... or convert to plain text bye.
I can confirm this problem still exists in 38.2. It seems to be more frequent when forwarding/replying email that include pictures, but it also happens if I have a draft of a simple text email open for a long time. I have been seeing it for years, but it seems to be more frequent in the last year or so. The work around I have found to work almost all of the time is to: -click "cancel", -then click "save" to save the email as a draft, -close the email -reopen the email from the draft, -then send. For whatever reason, this seems to almost always work. Once in a while, I have to copy all of my email to the clipboard(the text I am writing, not the forwarded content), delete the draft email, start a new email forward, paste in my text and immediately hit send. This has never failed that I can remember. FWIW, there definitely seems to be a time element to this. The longer I have a draft open, the more likely it is to hang upon send.
I didn't read all because there is a lot to read and I see this problem from a long ago, but the message above (from hoot) reports most of I will report. I believe that when you keep a message opened for a long time, maybe any other that you read replaces and then removes the reference than when you try to send the first one, there is no file to attach. I also got problems of wrong references showing wrong contents, but I can't remember exactly what happened on that case. If you do a print screen, cut the portion of the image regarding the problem and paste over the bad one (replacing it), it solves the problem but I really like to see it solved. If I'm not wrong, I have this kind of troubles since Netscape Composer. I hope to be helping fixing it.
Two new cases are found. bug 1201782 and bug 1202689.
Depends on: 1201782, 1202689
Summary: Sending reply to (or forward inline of) existing HTML message with embed images fails with never-ending error message: "attaching..." → Sending reply to (or forward inline of, or edit draft of) existing HTML message with embed images fails with never-ending error message: "attaching..."
I am using Thunderbird 38.2.0. When I reply to an e-mail which has graphics I sometimes have to go down through the e-mail thread and delete all the graphics (including the various graphics in signature files. (My favourite deletes are those little green leaves which everyone like to include in their signature files - not!) What a pain. It appears that there are two things that cause this: Try this: Tools Options Click on Composition Tab. Click on Composition General Tab. Unclick Auto Save every_minutes. (Turn this off.) OK For more information, see: Thunderbird Emails Client Won't Send, Hanging Forever, Saying "Attaching..." http://www.gabriolagraphics.com/thuderbird-email-client-wont-send-hanging-up-saying-attaching/ ALSO: Turn off automatic e-mail downloading by following these instructions: Tools Account Settings Server Settings Check for messages every xx minutes. Unclick this option. OK Shut down and restart Thunderbird to make the last change take effect. It will NOW be necessary to manually download e-mails, but I think e-mail downloading should not be done with a draft e-mail open. Save any draft e-mails before downloading new e-mails. (I have not checked this.) This is obviously a work around but it is better than the other work around (reinserting graphics) that I have had to use. /Paul
Related to Bug 1212495?
We have exactly the same problem as described in the first post still in the Thunderbird v. 38.3.0 on Windows 7 Ultimate x64!
(In reply to Miloš Havlíček from comment #159) > We have exactly the same problem as described in the first post still in the Thunderbird v. 38.3.0 (snip) If Tb 38 or newer, read bug 1201782.
It's 6 years old issue and there is still no solution for me. That's POP3 account.
Hello everybody, are you using Enigmail addon to sign/encrypt emails? I am asking this because I had the problem of the neverending message "Attaching" or "Sending" (I don't remember exactly the name). It happened only when I checked "Encrypt draft messages on saving" in the "OpenPGP security" options. I didn't need to encrypt my drafts so I unchecked it and have never seen the problem again.
Nope, this is NOT related to enigmail. At least in my case.
I found this post: http://www.gabriolagraphics.com/thuderbird-email-client-wont-send-hanging-up-saying-attaching/ It contains useful information that could help in fixing this really annoying bug.
(In reply to csongor from comment #164) > I found this post: > http://www.gabriolagraphics.com/thuderbird-email-client-wont-send-hanging-up- > saying-attaching/ > > It contains useful information that could help in fixing this really > annoying bug. No new info there, that blog/whatever was already referenced in comment 157. Even in a bug with this many comments, you should at least endeavor to read the last 10 or 20 comments before commenting yourself - or if you're hardcore, read them all.
Oops, sorry, you are absolutely right. I didn't recognise it. Unfortunately I cannot delete my comment. If someone can then please remove it. Thanks.
I have the exact same problem with thunderbird on my PC but it’s totally fine on my laptop with the same version (38.4.0) and the same set up, although a setting or two could be different, both on windows 7, my laptop is basically an identical clone of my PC. If it’s working fine on my laptop but not on my PC I’m thinking it can be fixed somehow, It’s a pain keep swapping computers to reply to emails with attachments but at least it works, any ideas guys?
And in 2016 with Thunderbird 38.4.0 on Linux the problem is still present !
I think there could be done a little improvement which doesn't solve the problem itself but makes the symptoms less painful. I think TB should check if there is such an embedded image in the email and if there is then it should display a message with two buttons: -------------- The mail body contains one or more embedded images. [REMOVE EMBEDDED IMAGES] [CANCEL SENDING] -------------- Or, if removing the images is not possible then this message should appear: -------------- The email cannot be sent because it contains one or more embedded images. [OK] -------------- I think any of these solutions would be better than the present behaviour when the user thinks they have to wait but TB doesn't do anything. Obviously, the long term solution would be to send these images normally but meanwhile this could be a temporary solution. What do you think?
today I tried sending a email and it wouldn't let me because it was trying to attach a broken link or something for 5 minutes or so before asking if I care for pontilhado.jpg. No thunderbird, I do not care for coporate signatures **** not being perfectly rendered on a email. It also would pop up like 7 error messages while trying to save it to the draft. This is kind of bad on a otherwise stellar email program.
Confirming what Hoot said above on 2015-08-28 19:13:35 PDT... I have had the same issue for a couple of years using Windows 7. It seems that if I write a reply to an email for several minutes and click send, then the "Attaching..." message appears forever. I can then cancel the send and copy the reply text before closing the reply without saving. I then click on the original message and reply again. I can paste my copied reply text into the message and it sends immediately with no problems. This seems to be unrelated to any enclosed graphics, though most emails these days do seem to be HTML. At one time I thought this bug may be due to Enigmail, but this is currently disabled so probably not.
(In reply to bill.lewis from comment #134) > It seems the code thinks the image in the original email is an attachment > but cannot find it . > > Either that or if it saves the original image to disk, it doesn't know how > to find it when you go to send a reply. This is an interesting comment. It implies that the image may be saved to /tmp - and if a reboot occurs between then and now, that file would disappear; at least under Linux. I have a semi-similar problem with LibreOffice whereby if LO crashes, it restores files from /tmp. However, if the OS crashes, those files from /tmp are deleted on reboot and LO is unable to find them, and never clears out its own references to that file, resulting in forever trying to restore a non-existent file.
Although I've had this exact problem, I now have an additional related problem. A fresh email (no replies) with multiple inline images stored locally - I was able to send out several copies of this email without issue. Then, for unknown reasons I was not able to send out another. I believe there was a reboot involved but I'm not 100% positive. If there was in fact a reboot, then /tmp files would have been deleted. It's also possible I may have moved where at least one of the images was stored, however I did try reinserting it from the new? location. Note that I had the composition window open with the message for literally weeks, and I copied the contents of that message to a fresh email (with minor text tweaks) and sent to different recipients over the course of those weeks. If I were the developer on this, I would check to see if /tmp is being used for anything anywhere, especially attachments. If so, change it to a less temporary directory and once that's done, do something about cleaning up old files left there. I would be happy to let someone take a look at my computer over teamviewer or similar if that would help. I'm using ubuntu 14.04
This has started to happen to me recently. It occurs when I reply to email that has images usually associated with the sender's signature. It also has started to happen when I include a screenshot in my reply. As I am composing and reviewing my reply, the graphics are perfectly normal. My workaround is to locate in the message thread each such signature-image, right-click on it and choose "delete". Then when I click send it sends my reply OK. Could failure to handle graphic images correctly be a Thunderbird configuration setting? I am a Windows 10 users, upgraded from Windows 7.
There is nothing that anyone can do to solve it. Just Thunderbird developers can do something changing the way Thunderbird handles the temporary files of this kind of messages. For some reason it loses the specific file associated with the signature or some other kind of images.
I have this problem too. It is the most annoying thing in Thunderbird. It usually happens when I try to reply or forward some e-mail with inline images.
Maybe OT here, but as Kent has mentioned here https://groups.google.com/forum/?fromgroups#!topic/tb-planning/osX4mab7lFI funding - or the lack of it - seems to prevent moving forward. So I am ready o act as a sponsor for this bug. Maybe more people would co-sponsor? Do we need a Kickstarter project do get rid of one of the most embarrassing deficiencies of TB? Or how else can we convert money to solutions?
After me begging for years, Mozilla is finally working on setting up a method so that Thunderbird could collect donations. Part of that process is asking donors to subscribe to an email list where we could solicit feedback from donors. We would like to send out a few messages per year asking donors to set priorities. That would be one possible method to allow people to advocate for particular bugs to be fixed, such as this one, with some financial backing behind it. Really it would be best if financial campaigns could have access to our tens of millions of users, such as we intend with an in-product solicitation of donations, rather than the hundred or so users who would see posts to this bug, or a similar number who might notice a kickstarter campaign. Also, Jorgk (candidate for Thunderbird Council who has been fixing compose bugs) is trying to organize a list of key bugs that we need to address, and one of his items is "Trouble Area: Problems with sending after attaching, Bug 453196 and maybe others" which is a sister bug to this one, and really the same issue. Perhaps Jorg can get interested in this area, and he has the skills to make it happen. (Though this is a difficult bug that requires a major rework of how embedded attachments are managed in compose).
Frankly, I think this bug has become too long and too confusing. I suggest to close it and open a new bug with a reproducible case. In this bug too many people are talking about too many problems. So, if someone can attach a message which fails upon reply or forward, I'm happy to look at it. BTW, I forwarded the message from attachment 520140 [details] with no problem. Yesterday I did an experiment and sent an e-mail with four pictures to myself: One attached, two inline (attached) and one inline with external reference (<img moz-do-not-send="true"). I forwarded the message with no problem. The only bug I could find with forwarded messages is bug 1251408 and I've already submitted a patch for it. Summary: No action will be taken until a *reproducible* case is presented.
I am able to reproduce the bug by doing the following on Thunderbird 38.5.1 using IMAP on Linux Mint 17.3: 1. Create a message that invokes the attachment feature 2. Attach a PDF 2. Wait 5 minutes 3. Click either "Send" or "File" and "Save" It appears there is not a specific message that will fail. Reproducing the bug appears to depend on waiting for a period of time after creating the message before trying to send or save it. I have tried disabling the auto-save and attachment features. This made no difference. Perhaps a session of some kind times out while waiting?
(In reply to Walter Coronel from comment #180) > I am able to reproduce the bug by doing the following on Thunderbird 38.5.1 > using IMAP on Linux Mint 17.3: > > 1. Create a message that invokes the attachment feature > 2. Attach a PDF > 2. Wait 5 minutes > 3. Click either "Send" or "File" and "Save" > > It appears there is not a specific message that will fail. Reproducing the > bug appears to depend on waiting for a period of time after creating the > message before trying to send or save it. > > I have tried disabling the auto-save and attachment features. This made no > difference. > > Perhaps a session of some kind times out while waiting? This has certainly been my experience. I have no problem sending or forwarding unless I happen to leave the draft open for a while. If I do, it will often get stuck in the "attaching" loop. I can generally save, close, and reopen to send it later, but sometimes I have to start over, copy the body into a new email and send immediately. FWIW, I think this is happening less often often in the last couple of months - don't know whether that is because of an update (I have installed several)or just that my behavior has changed.
As I said, this bug should be closed since too many people talk about too many problems. (In reply to Walter Coronel from comment #180) > 2. Attach a PDF Thanks for the example, but do you realise that you are in fact reporting another bug? Please read the summary: Sending reply to (or forward inline of, or edit draft of) existing HTML message with embed *images* fails with never-ending error message: "attaching..." What is reported in the summary I cannot reproduce, at least not on Windows where I develop. I will now try your example on Windows. My auto-save interval is set to 1 minute. When you say IMAP, you most likely mean that the draft is (auto-)saved into an Drafts folder on the IMAP server. I will try under those circumstances. I also have a Linux Mint 17.? installation, I can try that too.
OK, on Windows, on an IMAP account, created a draft, attached a PDF, waited until the auto-save kicked in to save the draft in the Drafts folder on the IMAP server, then sent. Result: worked. I've done it another time, this time I waited longer, still worked. So your steps to reproduce don't describe a case which fails 100%. There must be another element of some action happening in parallel which you haven't described here that makes the problem occur. Let's read Hoot's comment #181 carefully: I have *no problem* sending or forwarding unless I happen to *leave the draft open for a while*. If I do, it will *often* get stuck in the "attaching" loop. I can generally save, close, and reopen to send it later, but *sometimes* I have to start over, copy the body into a new email and send immediately. So you're both describing an intermittent problem which seems to have nothing to do with images (as per the summary). No one so far has been able to name the missing element that causes the failure. That's why we're at comment #183, people are desperate, but nothing was fixed so far. Instead of paying TB development to fix the bug, we should pay a bounty to the person who presents a reproducible case.
Agreed, there have been many variations on attaching problems reported on this bug, but the original one pertains to embedded images in the original email when replying or forwarding and is still valid. I have multiple accounts and I can only reproduce this on messages that digitally sign the email. On the accounts that don't use a digital signature, drafts are saved just fine, whereas the accounts that use a certificate are the ones where I encounter this. At the office, the two of us that use digital signatures are also the only two that experience this issue. Perhaps the issue with replying to emails that contain embedded images (and not the other attachment-related issues that have been mentioned) all occur as a result of a certificate being used to sign. (Or perhaps they are all related in some way.) I can reproduce it as follows: 1. Receive a mail on an IMAP account that is in HTML and contains embedded images (signatures, screenshots, etc.) 2. Make sure you are replying in HTML and from an account that has a certificate available and that the message is set to be digitally signed with it. The images should initially be visible in the email body. 3. Either wait a couple of minutes so that it saves to the Draft folder (also on IMAP) more than once (the more than once bit is important) or manually save the message at least twice (the first save seems to be fine, but subsequent ones break) 4. The images disappear and are replaced with a place holder and broken image icon. 5. Further attempts to either save to draft or send will result in the never-ending "Attaching..." message There was only one previous mention of digitally signed messages and that was in comment #162, however it specifically mentioned Enigmail, whereas I'm using the built-in signing capability of Thunderbird. Jorg K, I am happy to open a new issue that is specific to the issue of replying to emails with embedded images and when using a certificate to digitally sign the message, if required. (Thunderbird 38.6.0 on Windows 8.1 using a Comodo-issued email certificate)
(I had a Comodo-issued certificate, too. It expired after one year, no idea how to extend it. Do I need to get a new one every year?? That's madness.) You deserve a bounty. 100% reproducible on IMAP and POP (with storing the draft in a local folder): 1st save works, 2nd save works but loses image, 3rd save fails with "Attaching". BTW: I used a multipart message for my test, so plain text + HTML + image. Please raise another bug for this with the following summary: Saving draft of signed message hangs with message "Attaching" if draft is a reply or forwarded message with embedded (attached) image. "Embedded image" shall mean: image embedded in the HTML text and *attached* to the message. Note that the some people have an image in a signature which is a reference to an image on the internet and is not attached to the message. Use "View > Message Source" to check for attached embedded images. This does NOT fail when simply referencing an image from a website in the HTML. Please copy your STR (steps to reproduce) to the new bug. Also note there that the "embedded" image must be attached to the message. Please post a comment here saying: Reproducible case of signed message moved to bug 12xxyyy. OK, anyone else wants to present a reproducible case ;-) We're still looking for something without signing.
Reproducible case of signed message moved to bug 1251853.
There is a discussion at the link below - in brief it says the issue is caused by Autosave, the second time it saves. Disabling Autosave is said to workaround the issue. https://sourceforge.net/p/enigmail/bugs/390/ Additionally, Autosave fails on the second and subsequent attempts
This issue is not restricted to Autosave. I have disabled Autosave for over 6 months now and I still get stuck with the message that shows "Attaching...". For me the issue happens only while replying, never while composing a new mail. Most of the mail footers nowadays contain images/icons with links like Facebook, Twitter etc. When the message is retrieved by Thunderbird, it seems to be adding a link to the image/icon file on the IMAP Server and turns on "Attach this image to the message" flag. I am providing an example of an image link to my account on Yahoo IMAP Server: "imap://murali%40pmibangalorechapter%2Eorg@imap.mail.yahoo.com:993/fetch%3EUID%3E/INBOX%3E85561?part=1.4&filename=image003.jpg". When I replay to the message all of this is copied to the reply message. When I hit the send button, Thunderbird tries to retrieve all images that have the flag "Attach this image to the message". It appears that at least for Yahoo mail, this IMAP fetch service does not seem to work. Hence Thunderbird hangs with the "Attaching..." message and the reply never gets sent. The way I solve this is to hit Cancel and then either disable the "Attach this image to the message" flag under each image in the original message or when hard pressed for time, just delete those images. I am not sure of why the following are done: a) Turn on the flag "Attach this image to the message" while retrieving a message from IMAP Server b) Why try to process any content in the original message I feel that just changing the policy related to (a) will solve the issue. There are no options available to disable this flag.
Thank you for your update Murali, and I have been testing the point that I raised and I confirm your point that the issue can still occur with autosave disabled. Regarding the IMAP server aspect you mentioned, this issue also happens with POP access to Gmail using the server pop.gmail.com
I have the same issue. Im not using IMAP, just POP. Small images inside the mail does not want to be attached. Not all of them - but some. Mostly footnotes. Imagine deleting 50 JPGS before sending a biz mail to push it out. It comes back as thread continue, then you need to delete new ones etc. Sometimes if this is not a footnote Im trying to delete every JPG pasted into text. But this way Im loosing track and confirmation about what Im discussing with someone which is not acceptable.
update: I cant send it when I "reply to all" I wont copy and paste as there is usually 1 'TO' and many 'CC' I tried to forward these messages to me. So I cant reply. But can forward to myself...
Whiteboard: [gs] [Read Comment 114 before commenting] [this bug collects cases other than bug 453196, bugs pointed in bug 453196, and bug 817245] → [Before commenting, Read Comment 114, and see bug 1201782 if your problem started in TB38][this bug collects cases other than bug 453196, bugs pointed in bug 453196, and bug 817245]
Is this bug related only to via proxy-server internet?
I had the problem both when I use and when I don't use proxy servers, so I don't think proxy servers are the problem. FWIW - I have noticed the problem less in the past few months. Used to hit me every day. Now it is much rarer. Don't know whether something got fixed or if I have just changed my habits to accommodate it.
(In reply to hoot from comment #194) > I had the problem both when I use and when I don't use proxy servers, so I > don't think proxy servers are the problem. > FWIW - I have noticed the problem less in the past few months. Used to hit > me every day. Now it is much rarer. Don't know whether something got fixed > or if I have just changed my habits to accommodate it. Certainly you've changed your habits. I got the problem today. I believe that is the longest issue with thunderbird without solution and if I'm not wrong, it comes from Netscape Communicator still.
I also got this error last week with the newest Thunderbird version 46.0.1. Steps to reproduce this behavior: Reply to a message with an embedded graphic, for example a company logo. Let the message window open for about 30 minutes. Then press send and the attaching-message will stay forever. Then cancel the sending, delete all embedded graphics from the message and press send again. Now Thunderbird will send the mail. We don't use proxy servers.
(In reply to Hans Peter Kunz from comment #196) > I also got this error last week with the newest Thunderbird version 46.0.1. > Steps to reproduce this behavior: Reply to a message with an embedded > graphic, for example a company logo. Let the message window open for about > 30 minutes. Then press send and the attaching-message will stay forever. > Then cancel the sending, delete all embedded graphics from the message and > press send again. Now Thunderbird will send the mail. > We don't use proxy servers. Same issue with 45.1.0
Just noticed an interesting variant of the behaviour with TB 45.1.0, W7P, no proxy, IMAPS/SSMTP: Leave mail with embedded images open for 30 minutes, send->hangs (up to here everything like always) NEW: leave the hanging send window open, change to another mailbox, open a mail - boom - the original mail is being sent, including the images. (this whole action was performed ca. 2 minutes after the send window went into 'hang'). This looks to me like some event or poll deadlock/race condition that can be recovered by triggering other events. Maybe just a coincidence? Maybe a re-opened IMAP connection? I will look into that more in the coming days and report.
I just discovered this bug. In my case, the images were png screenshots, not in the signature. The mail I received had 2 png, I added 3 more in my reply and Thunderbird hanged when attaching the images. I tried Peer Tavori's procedure but it did not work. I even created a new mail (with no images but with an attachment) and successfully sent it. My "png" mail was still unsuccessfully attaching images after this. Removing the all png from citation allowed me to send my mail.
OK, comment #200 is mine! I have been looking into the related bug 453196. The endless loop "Attaching ..." is caused by a broken reference to an image. Basically an image in a message references an image embedded in another message, which can be a previous draft of the same message, like this: <img src="mailbox:///[path to the mailbox]?number=[nn]&amp;header=quotebody&amp;part=[part]&amp;filename=..."> If the referenced message disappears for some reason or the MIME parts of that message change (like in bug 1251853), the reference will be broken and saving/sending the message with the broken reference will cause the endless "Attaching ...". Now, people who want to help to find causes need to do the following: They need to install the add-on ThunderHTMLedit, so they can inspect the HTML of the message which causes the hang. When the problem happens, they need to press "Cancel" on the "Attaching" panel and inspect the message looking for image references. Then, they need to visit the mailbox which is referenced in the image reference and switch on the "Order Received" column to see the message numbers. If a message with the referenced number cannot be found, we know why the problem happens. If a message with the referenced number can be found, the MIME parts need to be inspected. To do this, the preference mailnews.display.show_all_body_parts_menu needs to be set, and then on the View menu, "Message Body As > All Body Parts" can be used. No one said that it would be easy. *** PLEASE NO MORE COMMENTS "this happens to me, too" without providing the requested details !!! *** If you want this fixed, you MUST deliver a case with all the details. If it can be reproduced, great. But it's also very important to find out the details of the cases that cause the hang.
(In reply to Peer Tavori from comment #198) > Just noticed an interesting variant of the behaviour with TB 45.1.0, W7P, no > proxy, IMAPS/SSMTP: > > Leave mail with embedded images open for 30 minutes, send->hangs (up to here > everything like always) > > NEW: leave the hanging send window open, change to another mailbox, open a > mail - boom - the original mail is being sent, including the images. (this > whole action was performed ca. 2 minutes after the send window went into > 'hang'). > > This looks to me like some event or poll deadlock/race condition that can be > recovered by triggering other events. Maybe just a coincidence? Maybe a > re-opened IMAP connection? I will look into that more in the coming days and > report. As promised I have investigated further. I have EditHTML installed which essentially does the same thing as ThunderHTMLedit. Findings: - No correlation with opening other imaps/smtps connects/mailboxes etc - so this was probably a coincidence before. - When the process hangs there was no SMTPS connection open (according to W7 netstat) but 4 IMAPS connections. - I tried Jorg's procedure to look at HTML; but then I had to jump and help someone, so I simply closed the message and tried to send again. And it went out as planned - including images. It had hung for 20 minutes before. - next time the bug occurs I'll check for missing references. - BTW: the mail I responded to was formatted in the weird outlook/Word 15 HTML variant
(In reply to Peer Tavori from comment #201) > - I tried Jorg's procedure to look at HTML; but then I had to jump and help > someone, so I simply closed the message and tried to send again. And it went > out as planned - including images. It had hung for 20 minutes before. The essential part is looking at the HTML content. When replying to a message from an IMAP server, the reference will look like: <img src="imap://info%40domain%2Ecom@server.com:993/fetch%3EUID%3E.INBOX%3E58?header=quotebody&amp;part=1.2&amp;filename=xxx.png"> If the connection to the IMAP server doesn't work, that attaching the image won't work. It would of course also be good to use a simple example. I don't understand this bit: "I simply closed the message and tried to send again". "Close" means "save draft", or "close" means discard? So how do you then send it again?
Of course 'close' in the sense of 'discard' or 'abort send', because that's the only option in the modal when a message hangs. So I 'aborted the hanging send' and when I came back to my desk I just pressed the send button in my compose window again and all worked fine. All clear? I'm still waiting for next bug to fire so I can look into broken src tags. Will report ASAP.
(In reply to Peer Tavori from comment #204) > So I 'aborted the hanging send' and when I came back to my desk I just > pressed the send button in my compose window again and all worked fine. OK, so the very same message caused a hang and later was sent correctly? Here is the problem: The message composition can contain references to other resources, typically images. At send time, we assemble the message to be sent out, but due to incorrect error handling, in case a resource to be included into the message isn't available, the send operation doesn't stop with an error "Error attaching xxx", but is seems to hang. I was looking into improving the error handling and message in bug 453196, however, the boss wasn't happy with the approach, so this will take a little longer. Now your case is a very good example of a resource to be included in the message temporarily being unavailable. Unless we change the architecture completely, that is, draw in all the resources/images at compose time instead of including them at send time, the attaching error will always happen if a resource that was available at compose time in no longer available or temporarily not available at message assembly time. That can happen because we were accessing a part of another message that got moved/deleted or changed its key due to compaction. Or in case of IMAP, the message may not be available from the server. Without changing the architecture, we still need to change the message assembly process to issue a clear error should a resource not be available.
I have one observation that may affect the decision whether to change the architecture or the assembly process. Unfortunately, while my experience happened on two occasions I have not been able to reproduce it at will. In the first case I had responded to a customer's email that contained some screenshots. The mail apparently was sent with no problem, but when I received his reply back I noticed that two of the inline images were pictures I had sent to another customer, resized to fit in the space of the images I would have expected. When I went back to my sent folder I noticed my reply had gone out with those images. The second case is similar, except I think I noticed it prior to sending the mail. In this case, my draft folder contained two auto-saves of the message, about 5 minutes apart, one with the correct images and the other with incorrect images (distorted by resize). After the second case I felt that I had to abandon TB for my business email until this issue is resolved. These cases did not involve any sensitive information in the incorrect images, but I could not risk the possibility of that happening in the future. I believe I still have the case 2 drafts in my folder if there is analysis on them that may help. If you think this warrants a new bug report (even though it's not reproducible) or inclusion in another bug, please let me know.
I believe the inclusion of wrong images is already reported in bug 1201782. Changing the architecture of the composition and assembly process would change all problems that arise from changed or invalid references. I think it's best to switch auto-compaction off, so nothing unexpected happens behind your back. And of course, while your composing an e-mail, avoid shuffling other messages around.
I experience problems with 'sophisticated' signatures containing html links etc every day now (this is because I have more contact with people using these). I wonder about two things: 1. is the only functioning work around deleting of these conflicting links (in my case in signatures of mails I have to answer) and 2. is there a planned fix and if so when? Ok so these are 3 questions. Can we have answers to them? /br
We're looking into improving the error handling in bug 453196. To be released in TB 52 in 2017 or in a beta version earlier. We have also plans to rework the compose pipeline to eliminate the source of these problems. That's not going to happen soon, though. Note: TB is free software. TB development is driven completely by (unpaid and overworked) volunteers. Users reporting a problem can get involved in the development themselves (that's how I started) or hire someone to investigate their favourite bug.
Just ran in to the problem agein. As promised, I have now run Jorg's procedure. Here's the result: TB 45.1.1, IMAPS/SMTPS to our corproate dovecot/postfix server. Message hangs on attach. HTML view reveals the following img tags: imap://userxxx@ourserver:993/fetch%3EUID%3E/INBOX%3E155111?header=quotebody&amp;part=1.1.2&amp;filename=image001.gif imap://userxxx@ourserver:993/fetch%3EUID%3E/INBOX%3E155111?header=quotebody&amp;part=1.1.3&amp;filename=image002.jpg Message No. 155111 is the original message that I am trying to reply to. The message is perfectly accessible, including images. The funny thing: Even when I open the original Message 15111 and try to save the reply to a draft, the saving process will hang on attachment. So one TB window can perfectly access the img, another cannot - at the same time. So I took the analysis one step further, looking at the original message 155111 with a Ctrl-E. The img tags look like this: imap://userxxx@ourserver:993/fetch%3EUID%3E/INBOX%3E155111?part=1.1.2&amp;filename=image001.gif imap://userxxx@ourserver:993/fetch%3EUID%3E/INBOX%3E155111?part=1.1.3&amp;filename=image002.jpg and the message can be saved with attachments as draft, no problem. Notice the difference? The problemeatic tags have 'header=quotebody&' added in the image URL. Next step: Assuming that this is the source of the problem, I went back to the hanging message and edited the HTML to delete the 'header=quotebody&' from the img URLs. And the hang is gone. So clearly the fact that TB somehow introduces 'header=quotebody&' causes the hang in my case. Hope this helps to finally kill this bug for good.
Thanks for looking into it. You are right, in a reply, the image is referenced as, for exaple (my testcase): src="imap://info%40hostalpancheta%2Ees@mail.hostalpancheta.es:993/fetch%3EUID%3E.INBOX.SPAM%3E63?header=quotebody&amp;part=1.2&amp;filename=lijbmghmkilicioj.png" and in an "edit as new" it's src="imap://info%40hostalpancheta%2Ees@mail.hostalpancheta.es:993/fetch%3EUID%3E.INBOX.SPAM%3E63?part=1.2&amp;filename=lijbmghmkilicioj.png" I don't think the header=quotebody makes any difference since all replies are sent with this and your replies mostly work, don't they? As you reported in comment #204, after a while a message that previously hung was sent without a problem. So I think what happened here is that you spent some time trying different things and after a while the message was sent successfully, and it would have been sent successfully without removing the header=quotebody. We made some changes in bug 453196 which will be included in TB 48 beta that's coming out in the next couple of weeks. I suggest you continue your investigation with that version. If you want to be more "bleeding edge", you could try a Daily. I'm using the Daily of 2016-06-24 since that date and I haven't found any problems yet. You can download it from here: http://ftp.mozilla.org/pub/thunderbird/nightly/2016/06/2016-06-24-03-02-18-comm-central/thunderbird-50.0a1.en-US.win32.installer.exe You can use any other Daily version after that date, too, but Dailies at times have problems. The one I'm recommending seems fine so far ;-)
Thanks for the link - I will try and report. I order to verify Jorg's assesment I tried the following: Create a new mail, edit the HTML to contain both type of img tags (with/without 'header=quotebody&') Result: saving as draft an sending works fine. So 'header=quotebody&' cannot be the reason, at least not the only one, if at all. But quite honestly I am not convinced that Bug 453196 and this one are really related, other than a lack of detail in error messages. The reason is found in https://bugzilla.mozilla.org/show_bug.cgi?id=532395#c210: "So one TB window can perfectly access the img, another cannot - at the same time." So I am hoping for the next occurence to investigate. In the meantime I was wondering if a dovecot parameter could possibly be the true reason for all this: mail_max_userip_connections. In most dovecot installations I have seen this is set to 10 or 20 in order to prevent bombing. It seems that TB is liberally consuming such server connections, assuming they cost nothing more than fresh air. Now imagine that someone is running a couple of mobile devices with the same user ID and a TB PC in the same remote WiFi network, which causes them to appear to come from the same IP, possibly triggering the server limit. Another thing to investigate. (IMHO this referencing of attachments via extra imap connections is a questionable behaviour on its own, because it assumes robust, high-bandwith and cost-free IP connectivity and unlimited server resources. In reality it wastes bandwith and kills performance on slow lines like remote and/or mobile connections; but that's another discusssion, that some people already seem to have for a long time; at least it helps me to finally understand TB's terrible performance over mobile hotspots.)
(In reply to Peer Tavori from comment #212) > But quite honestly I am not convinced that Bug 453196 and this one are > really related, other than a lack of detail in error messages. The changes in bug 453196 did this: The endless "Attaching ..." won't occur any more, instead you will get an exact message about which attachment can't be accessed. We hope that this will bring us nearer to the cause of the problem. Our resident IMAP expert also tweaked IMAP processing here: https://hg.mozilla.org/comm-central/rev/40f4c524ba0b#l4.13 and said about the change: "We are adding a new listener in a very common path. I don't really understand how it worked at all before, but obviously it did ...". So maybe that change has some effect. It would therefore be good to use a version of TB that contains the change to try it out. > (IMHO this referencing of attachments via extra imap connections is a > questionable behaviour on its own, ... To be honest, I don't know whether attachments are really fetched again from the IMAP server or whether they are retrieved from the local store since IMAP messages get stored locally. Sadly I'm not an IMAP expert at all. Of course you are right that referencing embedded images from other messages is not a good idea. We have plans to change that since we are in the (very slow) process of reworking the whole composition pipeline. We have already discussed this in bug 453196 comment #23 (down to bug 453196 comment #26).
(In reply to Peer Tavori from comment #212) > So I am hoping for the next occurrence to investigate. Maybe instead of hoping and waiting you could actually provoke the problem and get us a reproducible case. Maybe by reducing your IMAP connection limit. According to comment #185 that will earn you 100 rubber points ;-)
(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #214) > (In reply to Peer Tavori from comment #212) > > So I am hoping for the next occurrence to investigate. > Maybe instead of hoping and waiting you could actually provoke the problem > and get us a reproducible case. Maybe by reducing your IMAP connection > limit. According to comment #185 that will earn you 100 rubber points ;-) Considering the impact of this bug and interest in getting it fixed, it would be a good idea for those fixing it to provide a 'reference' version for those of us willing to test it to use?
(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #200) > If you want this fixed, you MUST deliver a case with all the details. If it > can be reproduced, great. But it's also very important to find out the > details of the cases that cause the hang. Jorg: I am not a coder so I've stayed away from making an account here, but I want to help with this bug since I reply to a lot of mail with company logos in them and frequently get interrupted for long enough to invoke several draft auto-saves and cause this issue. Note I am using POP3 mail here, not IMAP. (I think IMAP is a blind alley here.) Currently TB 45.2.0 on Win 7. Last week I managed to deliberately invoke this problem. Going through your steps, the Drafts?number= reference turned out to be one number higher than the existing copy of the mail in the Drafts folder. At which point it started complaining about not being able to save the draft anymore in addition to not being able to send. I thought, mystery solved, and tried to do it again just to make sure. Catch it in the act, as it were. For the rest of the day I couldn't get it to recur, I watched the number increment in both the draft folder and in the html source of the mail in the open compose window, every five minutes (the auto-save time period) if I'd made a change to the text of the reply since the last save. Today it happened again, same apparent cause. The compose window html source referred to the image as Drafts?number=222 while the mail in the drafts folder was only number 221. (Lots of old drafts in there that somehow didn't self-delete when I finally sent the messages. I really should empty that out sometime.) Though once again I had trouble reproducing it a second time. I tried not leaving TB open on the Drafts folder. I tried compacting the Drafts folder to reset the numbers to start at 221. Then I closed and restarted Thunderbird entirely. That did the trick, though oddly the compose window made it to Drafts?number=226 that time while the copy in the drafts folder was still just 221. Fixing the reference to number=221 of course allowed the mail to send. The next attempt was to restart Thunderbird and watch the Drafts folder, which didn't produce the bug's effects. Restarting and again NOT watching the drafts folder got the compose window stuck on Drafts?number=229 while the draft folder copy had number 222. I'm not entirely sure how it's actually picking these numbers now, is it influenced by the actual messages in the draft folder or by the deleted-but-not-compacted messages there? I do note that if the compose window and the draft folder copy are synced, closing the compose window causes the draft folder copy to remove itself. However if they are in a number mis-match with the compose window hung on "attaching" in the status bar, closing it leaves the draft folder copy intact. I don't know if it's worth suggesting to never move the reference off the original message (e.g. in the inbox) in the first place, which currently doesn't happen until the second auto-save anyway. I know that's not foolproof, but at this point it seems more likely that the reply will end up pointing to a non-existent place in the drafts folder than it is that someone will archive/delete/move the message they are replying to before actually sending the reply. If you have any suggestions on more combinations of factors to investigate, I would be happy to give it a try.
FWIW, I agree that IMAP is a blind alley. I experience the problem on multiple accounts - all POP3.
Ray: Thanks for the investigation. A few comments: The second (auto-)save changes the reference from the original message to the drafts folder. I'd have to see why we do that. Not moving the reference would make things safer, as you pointed out. You're saying: "Last week I managed to deliberately invoke this problem." Unless I misunderstood something, this is not the case. Yes, you observed a few occurrences, but you can't cause the problem at will, or can you? You're using ThunderHTMLEdit to look at the HTML source, right? I've just noticed that this has a bug. When the message is (auto-)saved, the reference number increases, yet the increase is not shown in the HTML tab. For example pressing "save" repeatedly will increase the number in the drafts folder whereas the reference in the message remains unchanged and low. But if you type into the composition again without saving, then the HTML tab will update to the actual correct message. Sorry about this bug in the add-on. So mismatches where the reference seems lower that the number in the draft folder are explained by this add-on bug. However, your report a mismatch the other way around: Drafts folder number is *less* than reference in the message. That of course will cause the "Attaching ..." problem. This is interesting as a point of investigation, but we still can't cause this at will, or can we?
Kent, this this seems to be about message keys getting out of step, perhaps comment #217 rings a bell. It doesn't for me. I can't see how an image reference in a composition could ever reference a message with a number higher than what exists in the Drafts folder.
Flags: needinfo?(rkent)
Something occurred to me. Ray said that "watching" the drafts folder prevents the problem. We had a bug where the Draft folder's MSF file got deleted. Apparently that only happened when the Drafts folder was not open ("being watched"). So what may happen is that somehow the Drafs.msf gets deleted and then rebuilt resulting in lower numbers. Ray, why don't you compact and repair (right-click, Properties) the Drafts folder before proceeding further. That allocates new numbers starting at 1. It would really also be good to use a Daily version of TB or the next beta TB 48 to see whether it's any better.
"Something occurred to me. Ray said that "watching" the drafts folder prevents the problem. We had a bug where the Draft folder's MSF file got deleted. Apparently that only happened when the Drafts folder was not open ("being watched"). So what may happen is that somehow the Drafs.msf gets deleted and then rebuilt resulting in lower numbers" I suppose that is possible, and perhaps is a good clue on how a reproducible case might be recreated. I don't really have any other ideas. This code is very difficult to work with, as you saw in the other hang bug that we fixed, so really without a reproducible case there is no hope of progress.
Flags: needinfo?(rkent)
As I said in comment #221, I think this problem here is another facet of bug 1216914 (access restricted) with duplicate bug 482836. What happens is this: The user works in an office environment with frequent interruptions. While answering a message, he goes to look at other messages. When he hits a "killer message", his Drafts.msf gets deleted. Later on the Drafts.msf gets recreated of course handing out new message keys and invalidating all references in open compositions. One symptom of the deleted and recreated Drafts.msf are many superseded drafts what spring back to life. This is exactly what the user is reporting (quote): "Lots of old drafts in there that somehow didn't self-delete when I finally sent the messages." I think we can rest our case here. This problem is already fixed in the current beta TB 47 and better error messages arrive in TB 48 due to the fix in bug 453196. The only thing I'd like to do here is investigate why we switch the reference from the original folder to the Drafts folder on the second (auto-)save. Kent, do you know?
Flags: needinfo?(rkent)
"The only thing I'd like to do here is investigate why we switch the reference from the original folder to the Drafts folder on the second (auto-)save. Kent, do you know?" No, I really don't know this code well, I only get familiar with it when I need to debug or review something.
Flags: needinfo?(rkent)
(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #219) > You're saying: "Last week I managed to deliberately invoke this problem." > Unless I misunderstood something, this is not the case. Yes, you observed a > few occurrences, but you can't cause the problem at will, or can you? Well, if you had asked me a month ago, I would have said that every time this bug hits me it turns out to be a reply to a mail with a company logo in the other guy's signature, and an instance where for various reasons it took a long time between starting the reply and hitting send. And I would have said the bug hits every time those circumstances occur, though thinking about it today that would be an unproven statement. Last week I set out to deliberately invoke the bug with those circumstances, and it worked the first time only. Yesterday I got hit with it in the normal course of my workday, and I set out to deliberately invoke it a second time, which as I said wasn't succeeding until I both restarted TB and didn't look into the Drafts folder until after the attaching hang occurred. > You're using ThunderHTMLEdit to look at the HTML source, right? I've just > noticed that this has a bug. When the message is (auto-)saved, the reference > number increases, yet the increase is not shown in the HTML tab. For example > pressing "save" repeatedly will increase the number in the drafts folder > whereas the reference in the message remains unchanged and low. But if you > type into the composition again without saving, then the HTML tab will > update to the actual correct message. Sorry about this bug in the add-on. So > mismatches where the reference seems lower that the number in the draft > folder are explained by this add-on bug. I am using that Add-on but haven't seen that behavior. Though I have not been pressing save, only waiting out the five minute auto-save period. I did notice that it seems to skip the auto-save if I've not typed anything since the previous one, which makes sense. > This is interesting as a point of investigation, but we still can't cause > this at will, or can we? That's a definite maybe. I'm more confident of that than I was a week ago. On my system, anyway. (In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #221) > Something occurred to me. Ray said that "watching" the drafts folder > prevents the problem. We had a bug where the Draft folder's MSF file got > deleted. Apparently that only happened when the Drafts folder was not open > ("being watched"). So what may happen is that somehow the Drafs.msf gets > deleted and then rebuilt resulting in lower numbers. > > Ray, why don't you compact and repair (right-click, Properties) the Drafts > folder before proceeding further. That allocates new numbers starting at 1. > > It would really also be good to use a Daily version of TB or the next beta > TB 48 to see whether it's any better. I did do that compact yesterday, to start the numbers over at 221 (I was up in the 230s at some point with all the auto-saves I was allowing to happen). That didn't bring the bug back, the next thing I tried after that was restarting TB, which did work as long as I didn't click into the Drafts folder prior to the message and its draft copy falling out of sync. Sounds like I should go ahead and empty out the Drafts folder, too, so it's completely blank? It's got those 220 orphan drafts in there going back years, many of them multiple draft copies of the same mail (bug 482836 I suppose?), and I really don't need any of them. I can also keep the mail folder open in File Explorer to see if the Drafts.msf is falling to 0 kb at any point. If bug 1279344 etc. is the core issue here, then making it happen on-demand might be out of our hands, other than just waiting for it? One other curiosity, back in the TB 38 days, when this bug hit it turned out all you had to do to "fix" it was hit cancel, click into the drafts folder (rebuilding the .msf?), and go back and hit send. That stopped working with TB 45, but I always thought it seemed like a clue.
Yes, you should empty out the Draft folder for sure. Only leave the drafts you intend to send later, so down to a couple/few. Then compact it an repair it. As I said, the draft folder corruption (by erroneously deleting Drafts.msf) has been stopped, so if you use TB 47 beta, things should work better. You're actually confirming once again that the Drafts.msf deletion (bug 1216914/bug 482836) is the core of the problem since you said "hit cancel, click into the drafts folder (rebuilding the .msf? [YES!!])". Surely in TB 45 clicking on the folder still rebuilds the MSF (if it was deleted) and I'm not aware of any changes there. I can only stress it one more time: Clean out your drafts folder and use TB 47 beta to go forward. You can install TB 47 beta in parallel, just specify a different installation directory (like "Mozilla Thunderbird 47" at the end of the directory). You can operate with different versions on the same e-mail store, I have about five different ones installed. If you're nervous, make a backup first ;-) BTW, you mentioned bug 1279344. You're not storing your e-mail on a Windows EFS, or are you?
(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #226) > As I said, the draft folder corruption (by erroneously deleting Drafts.msf) > has been stopped, so if you use TB 47 beta, things should work better. > > You're actually confirming once again that the Drafts.msf deletion (bug > 1216914/bug 482836) is the core of the problem Can't view bug 1216914: "You are not authorized to access bug 1216914." So, any chance of that fix being uplifted for 45?
(In reply to Charles from comment #227) > Can't view bug 1216914: "You are not authorized to access bug 1216914." Now you can. > So, any chance of that fix being uplifted for 45? Ask/beg Kent ;-)
Actually, why don't you run TB 47 beta for a while to confirm that things are better?
(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #228) > (In reply to Charles from comment #227) > > Can't view bug 1216914: "You are not authorized to access bug 1216914." > Now you can. > > > So, any chance of that fix being uplifted for 45? > Ask/beg Kent ;-) Lol... (In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #229) > Actually, why don't you run TB 47 beta for a while to confirm that things > are better? Well, I would, but in all honesty, I can't remember the last time it happened to me. I don't know why. I just know that it still hits a lot of people, so anything that makes TB more stable is something I want to see.
I will look into beta 47/48. In the meantime, can confirm MSF is involved in the problem. I just watched this happen three times. Seems to play out like this: Hit reply with N messages in Drafts folder 5 minute mark: draft saved to number N+1 10 minute mark: draft N+1 deletes, draft N+2 created, in-line graphic reference is now to draft N+2 15 minute mark: Drafts.msf vanishes completely. Poof, gone. "Attaching..." shows in the status bar. Click into Drafts folder. Drafts.msf rebuilds, former N+2 draft is now N+1. Reference in active reply window is still to N+2. Not sure if it has anything to do with Windows EFS. Probably not, pretty sure I'm not running EFS. I just saw folks talking about that bug in relation to MSF files getting trashed. Why rebuilding the Drafts.msf fixed the problem instantly on TB 38 but not TB 45 is puzzling. Obviously in 38 upon rebuilding the MSF, the numbers matched up, while in 45 they do not. Now sure how that works out but TB 38 is no longer relevant. Also interesting, if I just close the reply, don't rebuild Drafts.msf, and start a reply to a second message, two things happen differently: 1) The graphic reference never changes to the Draft folder, it sticks to the original message. 2) When finally looking in the Drafts folder, there are multiple copies of the second reply at five minute intervals, it was unable to delete the previous one while creating the new ones.
I read in the message trail that this issue is caused by the movement of the location of the original message, say from one folder to another, before the composed reply is sent. In the reply being composed, the images from the original message are embedded as links to the original message on the server. By default Thunderbird also turns on the option to embed the image in the reply while sending. If the original message is moved to another address for any reason, the link references in the reply becomes invalid and Thunderbird waits for the images to become available to embed them in the reply. In my case, I figured that this could have been caused by use of a Thunderbird Add On called "Copy Sent to Current". This add-on helps in moving the sent message to a specified folder while sending. It also has an option to move the original message to the target folder while sending a reply. Unfortunately, the Add-on moves the original message from Inbox to the target folder even before sending the reply. This causes the image references in the reply to become invalid and Thunderbird waits forever to embed those images in the reply. I have checked this hypothesis by turning off the option to move the original message and I am having 100% success. I have provided this feedback to the developer. Hope the Add-on will be changed. I hope this helps the Thunderbird users to diagnose the problem.
(In reply to Ray Kremer from comment #231) > In the meantime, can confirm MSF is involved in the problem. Thank you for the perseverance and confirmation. Much appreciated. > Why rebuilding the Drafts.msf fixed the problem instantly on TB 38 but not > TB 45 is puzzling. Obviously in 38 upon rebuilding the MSF, the numbers > matched up, while in 45 they do not. Now sure how that works out but TB 38 > is no longer relevant. Aceman, Kent: Just out of interest, has the algorithm to hand out message keys changed when completely rebuilding the MSF between TB 38 and TB 45? I could only find bug 854798, but that already landed on TB 38. That says on the whiteboard: "'Repair folder' can still change messageKey and break linked things." Or maybe that got changed in bug 1183490 which did land on TB 45. > Also interesting, if I just close the reply, don't rebuild Drafts.msf, and > start a reply to a second message, two things happen differently: > 1) The graphic reference never changes to the Draft folder, it sticks to the > original message. That's indeed interesting. > 2) When finally looking in the Drafts folder, there are multiple copies of > the second reply at five minute intervals, it was unable to delete the > previous one while creating the new ones. That is the known faulty behaviour. That is exactly what is described in bug 1216914 (access-restricted). As you edit a message, more and more drafts are (auto-)saved superseding the previous one. When the MSF is rebuilt by clicking on the folder, all these come back to life since the were not marked deleted in the raw mailbox file. (In reply to Murali Santhanam from comment #232) > I hope this helps the Thunderbird users to diagnose the problem. Thanks for letting us know about the add-on problem.
Flags: needinfo?(rkent)
Flags: needinfo?(acelists)
At some point, and possibly between 38 and 45, we stopped matching message keys to offset in the mbox file, and started assigning keys incrementally from the previous key value.
Flags: needinfo?(rkent)
Thanks, that would explain it.
Flags: needinfo?(acelists)
But the answer to Jorg's question is that yes, when rebuilding/repairing a folder, all the keys are regenerated/renumbered with the (now new) algorithm so they may become different (for the same message). On compact or with normal folder operation a message that got a key assigned (with whatever algorithm) should never get that key changed later on. Yes, this change was between 38 and 45.
Blocks: 1287981
I am not a coder so a lot of this stuff goes right over my head, but I'd just like to say that this happens to me frequently because I use an html signature with images. It is not simply restricted to the drafts issue, but also with threads of replies. I use a folder for email templates. In order to send one of these I have to change my signature to a different one without images and then back again to the same one so that it refreshes the images before I can send the edited email. If I send an email to a client and he replies with my original email inline with the message; and then I reply again with my signature, it doesn't always send. I think it is time-related because sometimes it will send with two sets of images attached, and sometimes not. If there are multiple exchanges in the thread, I will always have to go through and delete my images from all resposes except the latest one before I can send a reply. This issue has been ongoing for me for years through multiple versions of TB. In my experience it has never been resolved. Wouldn't it be better to treat the images seperately so that they always retain the same references? Just a thought!
<off-topic> The proper way to embed an image into a signature would be to reference it from a website: <img moz-do-not-send="true" src="http://www.somesite.com/images/sig-image.png"> That way you avoid sending and receiving the same image over and over and over and over again. </off-topic>
Fyi, back when we used to embed images in our corporate sigs, they were embedded this way (I created the sigs myself), and we still saw this problem. Since then, we have removed these images, and also migrated to Office365 (ugh, against my wishes), so most of our users are now using Outlook (although a few like me hate Outlook and still use TB for email, but have to use Outlook for the corporate Calendars).
(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #238) > <off-topic> > The proper way to embed an image into a signature would be to reference it > from a website: > </off-topic> And recipients (TB by default) would block that remote content thus not getting the pleasure of viewing the most important corporate logo. That wouldn't pass in a corporation :)
I just encountered this problem again for the first time in several years. I was replying to a single email address which had an HTML signature in the original message. After typing a lengthy reply, I got the hang with the "attaching" message. Hitting "cancel" and sending again gave the same result. Until this is actually fixed, I may have found an easy workaround, especially for those who are replying to many addresses. After the second hang, I hit "cancel" again, but left the "Write" window open. I copied all the text in my reply, went back to my inbox and hit "Reply" again on the email - with the original reply window still open. I then pasted my reply text into the second "Reply" window, and hit send. The note went out immediately and successfully. I then went back an discarded the original "Reply" window. I wanted to post this for those who were trying to do a copy/paste into a "Send" note. I assume you can also use "Reply-all" in this example and get the same result. Again, this is just a workaround until someone fixes the code, but maybe it will also give some hint as to where the code problem lies. Good luck, all!
As for "Endless Attaching... loop for embed image in html mail"(symptom reported to this bug. issue of bug 453196 and bug 817245), "Endless loop" problem is already resolved as easily known by "FIXED of bug 453196 and bug 817245" at least in Thunderbird trunk nightly(50.0a1). - Dialog for action is shown instead of "endless attaching... loop", and composing HTML mail is saved by pressing "OK", with keeping obsolete <img src="cid:part1.FB438E40.723FFDF7@a.a.a" ...> in HTML mail source, without "embed image part in multipart/related" which couldn't be found. i.e. There is no need of "Cancel, remove erratic embed image in the composing HTML mail". Why "additional comments in this bug" are still needed? Outstanding crical issues are only phenomenon of bug 766495(wrong image)/bug 799450(text data for image), which are stated in bug 1201782, aren't it? Note: Even after great enhancement of "Compact keeps messageKey of existent mail" and "messageKey !=== Offset any more" are implemented, if Repair Folder is invoked while embed image of composing mail is pointing mailbox://...&number=XXX,..., and if messageKey=XXX is assigned to other mail in the Mbox by Repair Folder, and if the other mail of messageKey=XXX has corresponding part in multipart/??? for the image data of composing HTML mail, bug 766495(wrong image of other mail)/bug 799450(text data of otehr mail for image) still can occur. And, in bug 766495/bug 799450, "endless attaching... loop" did/does/will not occur.
I really would like a solution to this issue but WOW - so much unintelligible gobbeldeegook - I give up!
Sharonie: We believe that we have identified the main contributing factors for this bug and *fixed* them. Next week Thunderbird 49 beta will be available here https://www.mozilla.org/en-US/thunderbird/channel/ and you can see whether the problem persists in that version. I think we can close this bug to the public now.
Restrict Comments: true
Fixed by changing the handling of embedded images in an access-restricted bug. Some details in the bugs depending on meta-bug 1322155. This work will ship with TB 52 ESR in March 2017. Users can try this in an Earlybird version TB 52a2 after Dec. 5th, 2016. Earlybird 52a2 is still not available at https://www.mozilla.org/en-US/thunderbird/channel/ but can be downloaded from here: http://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-aurora/ or localised from http://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-aurora-l10n/ This is for expert users only. Remember that Earlybird TB 52a2 is "alpha" software, so your PC might explode ;-)
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 53.0
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: