Thunderbird hangs on send saying "attaching"

[erenes]

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...

[RayKremer]

BUG DESCRIPTION AND QUICK WORK-AROUND:

To reiterate, since a lot of people can't take the time to read over every page of the now very large thread, if there is an in-line graphic in mail that you are replying to/forwarding (e.g. a company logo in a signature) and the mail sits open long enough to get saved to the draft folder, when you finally hit send it is likely to get stuck on the message "Attaching..." The easy workaround that works for most folks is to hit cancel, click into the Drafts folder, then go back to the mail and hit send again. The typical surefire method is to just delete the images before reattempting the send. Shutting off the draft auto-save of course prevents this entirely.

(There may be other circumstances that invoke the same result, but that is the most common one.)

The six-year-old bugzilla thread on this problem is https://bugzilla.mozilla.org/show_bug.cgi?id=532395
A new bugzilla thread on this problem that aspires to a fresh start is https://bugzilla.mozilla.org/show_bug.cgi?id=1251853

Cause: As best I can tell. It appears when you are replying to a message and you end your reply message with a typed character, the send will often fail. It might fail with a "Attaching" message, or I want to say I've seen another situation where it hangs without that, but it's been a while.

Fix: (Well, workaround) At the end of your typed text, make sure you type a space or two and end your message with that. With the spaces on the end it never fails.

I don't know if you're experiencing a completely different problem than what I've seen, or if you're just vastly misidentifying the cause. A space is a typed character, it's on the ASCII table right before the exclamation mark. Thunderbird wouldn't be treating spaces differently from any letter, number, or punctuation mark.

Ernes:
I see that you are posting in the bugzilla thread. I have resisted joining over there since I am not a coder. Would you please pass along to them the workaround we have found? (Hit cancel to stop the send attempt, click into the Drafts folder, then go back to the mail and hit send again.) It is possible that knowing this behavior may help them identify the cause or a solution. From the discussion at comment 185 it seems that it loses track of the images after the 2nd draft save, but forcing it to load the draft folder "reminds" it where the images are.

I, too, am using POP, not IMAP. I cannot confirm or deny that my "account that has a certificate available and that the message is set to be digitally signed with it". I don't think there is, but I wouldn't swear to it.

[jericoserilico]

thanks for the "Draft" workaround, I was finally able to send the message with all the images included after reloading from the "draft" folder

However there is another quick workaround if you don't mind to lose images, I click on "rewrap" , in the "edit" menu. I lose the all images, but at least I can quickly send the message in plain text, without going through all the quoted part to erase little jpegs and gifs in every signature footer, which in a long thread can take some minutes.

[MaxSouthOz]

. . . and when I move it to the Drafts folder, the bottom half of the message disappears and I have to retype it.

[RayKremer]

Oddly enough, the draft folder trick seems to no longer work for me, at least not the last two times I attempted it.

Usually it's simple enough to hit reply again and copy/paste from the ruined Compose window into the new one, but regardless this continues to be annoying.

No real movement in the bugzilla threads. Basically a lot of folks standing around, looking down at it, saying, "Yep, that's a problem alright."

Edit 5/24: Yep, draft folder work-around no longer does the trick. Gives me the message:

Sending of the message failed. There was an error attaching . Please check that you have access to the file.

What was saved in the draft folder hadn't caught up to the last of what I'd typed yet, but I hit "edit" on it anyway, which created an additional Compose window, and I copy/pasted my text over from the first Compose window.

Oh, but this is interesting. It seems just yesterday a person in the bugzilla thread has independently discovered the old trick, and in fact it wasn't specific to the draft folder. He also notes this works on TB 45, implying it does not on TB 46, which is true:

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've noticed some of these guys are hung up on the idea of a cause related to IMAP, despite being told multiple times that the issue affects POP users the same. Regardless, I've been thinking that some vital clue might lie in our old work-around, so hopefully this guy will figure something out finally.

[wmclaxton]

Using Thunderbird 45.1 and IMAP. I have had the same issue for years. It does not affect new mails with images - only replies to mails received with embedded images, typically the graphics in some corporate signature line.

The only solution seems to be to delete the images in the email thread before sending. Usually this is not a problem but there are cases where I want the images to be retained in the thread (eg- during tech support exchanges). I love Thunderbird too much, so I'm just working around the issue for now. But knowing that others are having the same problem is reassuring.

Adding my voice so that it may get some attention from the developers.

[Aleq]

Exactly, wmclaxton speaks from my heart. I have had this issue for YEARS. If I forward/reply to an e-mail and keep it open for longer period of time, there's no way how to send it. Only delete the inline images, which is super annoying. In the cases of emergency I had to use snipping tool to screenshot those images and replaced the original ones with the capped ones. Crazy.

What scared me the most in recent past was that several times my e-mails contains DIFFERENT images. I replied to an e-mail with image of horse and then saw in the sent mail a picture of dog (which I received/sent some time before that). The dimensions of the "dog" picture were taken from the "horse" picture, so it was stretched. This really frustrated me, what would happen if some senstive information was sent over? This did not happen luckily, but somehow I lost trust to Thunderbird at that time. This happened only few times and I'm not sure if it is not gone with the latest versions. It may be unrelated to this issue...

[RayKremer]

The bugzilla guys have taken notice of yet another old bug thread on the same issue: https://bugzilla.mozilla.org/show_bug.cgi?id=453196 taking it to a total of three that I know about. Odd thing is folks in there noticed early on that it was the same or a similar problem to https://bugzilla.mozilla.org/show_bug.cgi?id=532395 and yet kept them as separate bugs. Note that there are multiple things that can trigger this, including moving or deleting the message being replied to before send, and the auto-draft-save kicking in twice. It's just that most people aren't silly enough to move or delete the message while replying to it, while taking "too long" to finish before sending happens all the time.
And, holy cow, it looks like Jorg K over there has demonstrated the actual root of the problem where the draft save screws it up!

In the cases of emergency I had to use snipping tool to screenshot those images and replaced the original ones with the capped ones. Crazy.

Oh, that's way too much work. Just start a new reply from the original mail and copy/paste in what you wrote in the first window. Stuff only starts going downhill after the auto-draft-save kicks in, so if you can get it done and sent within a few minutes it's fine.

What scared me the most in recent past was that several times my e-mails contains DIFFERENT images. I replied to an e-mail with image of horse and then saw in the sent mail a picture of dog (which I received/sent some time before that). The dimensions of the "dog" picture were taken from the "horse" picture, so it was stretched. This really frustrated me, what would happen if some senstive information was sent over? This did not happen luckily, but somehow I lost trust to Thunderbird at that time. This happened only few times and I'm not sure if it is not gone with the latest versions. It may be unrelated to this issue...

If that were at all reproducible, it could be major help to the tech guys over in bugzilla. Never had it happen to me, though. Does lend credence to the idea that the draft saving process is misplacing the "location" of the images. Ah, and someone in the bugzilla thread going by yogi_john has mentioned the same happened to him. This seems to be yet another bug https://bugzilla.mozilla.org/show_bug.cgi?id=1201782 that is separate but similar or related to the main issue at hand here. Images in a reply are kept as pointers to the original message, but when a draft is saved twice the pointer is moved to point to the draft, which doesn't have the image. If other things happen that shuffle messages around, then the pointer might point to a image from a different message that is now in the same "place" as the original. And then there's https://bugzilla.mozilla.org/show_bug.cgi?id=877159 started three years ago which tries to put the focus on that larger issue of keeping an image pointer instead of the image itself. I guess the general cause of the problem has been understood for years without anybody wanting to rock the boat enough to fix it.

Some of this is nutty, though. In bug 453196 (problem when you move/delete the original before hitting send), Jorg K has repeated the old false claim that bug 532395 (problem when the auto-draft-save kicks in) hasn't been described in a reproducible fashion. And then he says "If it were such a big issue, someone should have already looked into it since the bug was first raised eight years ago." which is amazing part about open source volunteer-driven software, there's plenty of opportunity for major problems to go ignored if nobody cares enough to look into it. Eight years. That's insane. Sure, it's not a world-ending problem, but it's an obvious and glaring one. I think the auto-draft-save specific case could be fixed easily even without fixing the larger issue (by keeping the pointer set to the original mail rather than changing it to point to the draft), but nobody wants to even do that much. It does kind of look like Jorg K and Kent James have picked up the ball on this, though, so we might see something happen. Though they seem to be focusing initially on merely fixing the error message? I guess that's a step forward over being stuck on "attaching", though it won't actually help any users that aren't familiar with the issue.

[KurtPloc]

Well, it is now 2016 and I see nobody has resolved the issue of "attaching..." since 2012!
If some people get this error, that means thousands of people get the same error, so does anyone know what the problem is?
I know what causes it, but cannot fix it or find anywhere on the internet how to fix it, nobodies knows, but why does programmers not know, they designed it!

When I receive a message from someone with an image inserted into the body or signature, after a while when you Save or Send, it hangs on "Attaching...". There is no way of saving this, unless I copy my typed message to clipboard and start over again. It even does it when I start a new message with my Signature image, same thing, after a while it cannot Save or Send... it hangs on "Attaching..."

I have read through plenty newsgroups and google search, but the people not having this issue, does not understand it, even programmers don't understand this problem.

[RayKremer]

Well, it is now 2016 and I see nobody has resolved the issue of "attaching..." since 2012!
If some people get this error, that means thousands of people get the same error, so does anyone know what the problem is?
I know what causes it, but cannot fix it or find anywhere on the internet how to fix it, nobodies knows, but why does programmers not know, they designed it!

When I receive a message from someone with an image inserted into the body or signature, after a while when you Save or Send, it hangs on "Attaching...". There is no way of saving this, unless I copy my typed message to clipboard and start over again. It even does it when I start a new message with my Signature image, same thing, after a while it cannot Save or Send... it hangs on "Attaching..."

I have read through plenty newsgroups and google search, but the people not having this issue, does not understand it, even programmers don't understand this problem.

It isn't really the case that the cause is unknown, as I have recently learned by diving through a number of bugzilla threads. Also it should be noted that being an open source program, these things are done by volunteers, who come and go over time, resulting in a lot of code being maintained by people who did not, indeed, design it. It also results in bugs being fixed or ignored according to whimsy, which is quite frustrating.

The core problem is that when you reply to a message, the compose box doesn't grab copies of the inline images, it creates pointers to the images in the original message. Certain people have been lobbying for years to change this, although I think this sums it up: "We have also plans to rework the compose pipeline to eliminate the source of these problems. That's not going to happen soon, though."

So the problem this introduces is that various different events, including moving/deleting the original message before sending the reply, and the machinations of the auto-draft-save feature, can cause the pointer to not point to anything. (At which time the error handling falls apart on several levels, which is something they are currently trying to address.) In the case of moving the original message, the reason is obvious. In the case of the draft save, the pointer is getting altered, which breaks it. Exactly what and why is something that they have just recently started to try to determine.

[Sharonie2]

Has anyone found a solution to this yet? 190 posts - I cant read all these messages of people basically saying they have the same problem. Can anyone direct me to the post with the solution?

[RayKremer]

Has anyone found a solution to this yet? 190 posts - I cant read all these messages of people basically saying they have the same problem. Can anyone direct me to the post with the solution?

Sharonie, there's no real solution. I can tell you when it happens (combination of in-line images and several draft auto-saves occurring) and a little bit of why it happens (the image is kept as a reference to the image in the original mail, and then as a reference to the image in the draft, and then the reference breaks and points somewhere that doesn't exist) and that some of the TB coders have finally taken real interest in this over at the bugzilla site.

At this point the best resolutions are to either delete the images and hit send again, or start a new reply window and copy/paste your text into it and hit send before any auto-saves occur.

[RayKremer]

Okay. I want to cautiously say problem solved. I jumped into the bugzilla pool to try to help track this down, and something I said made them think of a different bug that they've already recently fixed (in beta 47), so I started examining that and it does appear to be that was the root cause. Basically the Drafts.msf file (.msf files are used by Thunderbird to keep track of the messages in each folder) is self-destructing upon the third auto-save, which (among other things) wrecks TB's ability to refer to the draft save that it's trying to work with and do image references from.

Assuming this is correct, the prevention options are now:
Use beta 47 until the bug fix makes its way to the mainstream release version
Finish and send the reply before the third auto-save
Bring up the drafts folder in the main window and leave it there until you send the reply, which prevents the .msf from going away (this was the clue I discovered that led to figuring it out)

Edit: Oh, and the reason for this:

Oddly enough, the draft folder trick seems to no longer work for me

has been identified as a change made between the version 38 and 45 releases of Thunderbird regarding the recreation of a missing msf file. Why it worked in 38 is one of those "spectacularly obvious in hindsight" things, although the connection to the msf file probably would have taken more time to track it down if it hadn't been something they'd already known about and fixed.

[phkhgh]

Okay. I want to cautiously say problem solved.

I don't see it fixed in TB 45.2.0.

Assuming this is correct, the prevention options are now:
Use beta 47 until the bug fix makes its way to the mainstream release version
Finish and send the reply before the third auto-save
Bring up the drafts folder in the main window and leave it there until you send the reply, which prevents the .msf from going away (this was the clue I discovered that led to figuring it out)

1) Now past v47b. Not working.
2) In latest fail, there was only 1 saved draft copy showing, when i tried to send the reply. But there should've been more, because it's set to auto save every 15 min & took > that to complete my reply. How long the copy that I was replying to (just hit "Reply") had been opened - don't know.
3) No sure what "bring up the drafts folder in the main windows & leave it there" means. (though you mention the trick may've stopped working after v38)

If you click on the Drafts folder - while working on the reply, once you click back on the edited reply copy, that takes focus away from Drafts folder - if that matters. Either way, it wouldn't send, but I didn't see the hanging "attaching" progress bar. This time, the error was an immediate "sending of message failed" - no err code or other description.

Only way I got it to send (which I've done before) is "edit as new" the last msg received. Then copy over (from another window) the new text & images I created for the reply. It sent immediately. So I used "edit as new" instead of hit reply button. Don't know how long I could work on the "edit as new" msg before it would also fail to send.

All this is a huge amt of work, when you need to leave important inline charts or screenshots. Hugely annoying bugs exist for yrs.
Just today, Jorg K reported in bug https://bugzilla.mozilla.org/show_bug.cgi?id=532395

We believe that we have identified the main contributing factors for this bug and *fixed* them.
Next week Thunderbird 49 beta will be available...

I think we can close this bug to the public now.

[RayKremer]

1) Now past v47b. Not working.

Ehhh. I just figured I would live with it until the next major release version and haven't tested things on any of the betas. Maybe I need to?

(Note that you have to actually download, install, and use the beta version to get the benefits. The bug fixes they are working on in the betas are not pushed to version 45 in the automatic updates. 45.2.0, 45.3.0 etc. only get things they consider to be vital/urgent fixes.)

2) In latest fail, there was only 1 saved draft copy showing, when i tried to send the reply. But there should've been more, because it's set to auto save every 15 min & took > that to complete my reply. How long the copy that I was replying to (just hit "Reply") had been opened - don't know.

Well, no. What it's supposed to do is delete the old draft when it creates the next one, which effectively just looks like it updated the one draft. Where things go off the rails is when the .msf file for the draft folder self destructs, then it loses track of the old draft and just makes a new one, leading to multiple draft copies present for the one mail. This is what led to that bug being discovered and fixed in the first place. The issue with the in-line image attachments seems to be an additional side effect of the same problem.

3) No sure what "bring up the drafts folder in the main windows & leave it there" means. (though you mention the trick may've stopped working after v38)

The main Thunderbird window, with the folder tree and the list of mails and such. Normally set to your inbox. When you hit Write or Reply it opens a second window to craft your e-mail in, but that main window is still there underneath on the inbox. If you switch that away from the inbox to the draft folder, then it (at least for me) prevents the self destruction of the drafts.msf file, even if you then go back to working in some other window.

The part that stopped working after 38 was in the rebuilding of the msf file. In 38 it rebuilds with the same message id numbers as before, thus solving the problem and allowing the message to send. In 45 it doesn't preserve the id numbers, so you have to stop the .msf from going away in the first place, or else copy/paste your reply into a new compose window.

This time, the error was an immediate "sending of message failed" - no err code or other description.

The improvement of the error reporting is supposed to also be enacted in the current beta. Which version are you currently using, again?