Stuck on saving mail to Sent or Drafts



6 years ago
3 years ago


(Reporter: trofimov.dmitry, Unassigned)


17 Branch

Firefox Tracking Flags

(Not tracked)



(1 attachment)



6 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130307122903

Steps to reproduce:

I send my mail.

Actual results:

Thunderbird sends mail but hangs on copying it to Sent folder.

Expected results:

Mail should be copied to Sent folder.

Comment 1

6 years ago
do you get a dialog message you can click?   or does it actually hang, broken, solid stuck?

Comment 2

6 years ago
I get dialog message which I can cancel. But if I don't press 'Cancel' it is shown forever trying to save the mail.

Comment 3

6 years ago
perhaps you could be more clear and complete?
if you did not press cancel, then when did you do?

steps please. for example
 1. did x
 2. did y
see Z

and, when/what release did it last work correctly?
Summary: Hangs on saving mail to Sent or Drafts → Stuck on saving mail to Sent or Drafts

Comment 4

6 years ago
Steps are:
1. I press Send
2. Mail is sent
3. I get a dialog showing a progress and a message about saving to Sent folder
4. It hangs forever
5. And yes I can cancel it and if I do it it doesn't save my sent mail to a Sent folder.

It stopped working recently but unfortunately I can't tell exactly whether it is connected with an update to new version. 

My current version is 17.0.4

Comment 5

4 years ago
I see this symptom fairly frequently, still in TB 31.  Here is a reproducer (not 100%, but frequent):

Mail is on an IMAP server, including drafts, sent and inbox.

Receive an e-mail with an in-line image.

Click reply (the incoming message is quoted).  

Type a bit, and start doing something else.

Auto-save to drafts will hang -- there is a message about attaching at the bottom of the 'saving' box.  And the in-line image(s) will be replaced with 'unreachable' boxes.  Manual save to drafts (^S) doesn't always hang.

Cancel and can continue drafting.  

Same issue on send.

Work-around is to select and delete each inline image from the original message (as quoted in the reply).

Now neither the save to drafts nor the send hangs.  But of course, the image isn't sent back.

I suspect that this has to do with the src="cid:part..." of the image and the image's Content-ID not being fixed-up as the reply is turned into a saved message.

This seems to happen more often with corporate logos on received e-mail than with, say, embedded photos.

Comment 6

3 years ago
Do you still see this when using version 38?
Have you tried Windows safe mode?
Flags: needinfo?(trofimov.dmitry)
Whiteboard: [closeme 2015-11-10]

Comment 7

3 years ago
We'd like to hear your current status, and have more information so we can move
your issue forward.
As it stand today, we are needing more information
Last Resolved: 3 years ago
Component: Untriaged → Message Compose Window
Flags: needinfo?(trofimov.dmitry)
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2015-11-10]

Comment 8

3 years ago
Yes, I still see this with TB 38.3

I have not tried "windows safe mode" as this is painful (and I don't believe it has anything to do with my experience.)

As I write this, I am replying to an e-mail.

The story with this e-mail:

I sent an e-mail with an in-line photo.

I received a reply, which quoted that e-mail, including the photo.

I am replying with a lengthy response, long enough that TB is checkpointing the reply.  Prior to the checkpoint, the photo was visible.

It's hung.  Says "Attaching..." on the bottom bar.  And the photo has been replaced by a "can't find it" placeholder.

I will attach a screenshot of the compose window and paste below the headers of the message to which I'm replying.

Note that if I select and delete the photo, then type ^S (save), the draft saves successfully.

This is why I believe that it has to do with the cid: not being fixed-up.

Here is the message (some parts xxx-d out for privacy).  I can provide the actual message off-line if required, but this shows the structure.

Return-Path: <xxxxxxxxxxxx>
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_IMAGE_RATIO_06,
	HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2
X-Spam-Date-Scanned: Fri, 13 Nov 2015 10:24:16 -0500
X-Spam-Bayes: score=0.0000 summary=Tokens: new, 98; hammy, 133; neutral, 153;
	spammy, 5.
X-Spam-Pyzor: Reported 0 times.
Received: from ( [])
	by (8.14.9/8.14.9) with ESMTP id tADFNv8J005177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
	for <xxxxxxxxxxxx>; Fri, 13 Nov 2015 10:24:00 -0500
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.98.7 at
Received: from unknown [] (EHLO xxxxxxxxxxxx)
	by over TLS secured channel
	with ESMTP id (envelope-from <xxxxxxxxxxxx>);
	Fri, 13 Nov 2015 08:24:00 -0700 (MST)
X-MXL-Hash: 564600906b83bcd2-cc7a0ff1c2e20125a62080fd5f03474e9a9be973
Received: from xxxxxxxxxxxx ([fe80::c57b:974b:46e9:3965]) by
 Txxxxxxxxxxxx ([fe80::c57b:974b:46e9:3965%14]) with mapi id
 14.03.0248.002; Fri, 13 Nov 2015 10:19:48 -0500
From: xxxxxxxxxxxx <xxxxxxxxxxxx>
To: xxxxxxxxxxxx <xxxxxxxxxxxx>
CC: xxxxxxxxxxxx <xxxxxxxxxxxx>,
Subject: RE: River street sidewalk (at MBTA bridge)
Thread-Topic: River street sidewalk (at MBTA bridge)
Thread-Index: AQHRG1N4srWMSaMQS0a710UNUnGgCp6aFk+A
Date: Fri, 13 Nov 2015 15:19:47 +0000
Message-ID: <5CEAD627603E524E9B657A26761FB99E851C5340@xxxxxxxxxxxx>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/related;
MIME-Version: 1.0
X-AnalysisOut: [v=2.1 cv=Trbg8Wjh c=1 sm=1 tr=0 a=vECa/7LPToMBkClA6+o3cg==]
X-AnalysisOut: [:117 a=vECa/7LPToMBkClA6+o3cg==:17 a=sG8L3YDLAAAA:8 a=YlVT]
X-AnalysisOut: [AMxIAAAA:8 a=N_PimFwoonAA:10 a=xqWC_Br6kY4A:10 a=qtqOOiqGO]
X-AnalysisOut: [CEA:10 a=EMONX4K_AAAA:8 a=OJfZtjMUAAAA:8 a=FAuCSCWHAAAA:8 ]
X-AnalysisOut: [a=JqEG_dyiAAAA:8 a=uS-zomLZAAAA:8 a=MbcnfYPhLaGdZbdea1MA:9]
X-AnalysisOut: [ a=QEXdDO2ut3YA:10 a=XcsqCHg4sHwA:10 a=c-gAvb3aHikA:10 a=7]
X-AnalysisOut: [ORwILNti2EA:10 a=Rk9jAid5bn8A:10 a=cMssq3yRJBcA:10 a=Uu0UU]
X-AnalysisOut: [HmML90A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=xgiRHN2t6hi]
X-AnalysisOut: [_EpWw:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0]
X-AnalysisOut: [A:10 a=frz4AuCg-hUA:10 a=Sbcq7Vw0X9D2ADy825gA:9 a=Y0egCgXd]
X-AnalysisOut: [e-9qDKv3:18 a=KQqxNPgzF0kA:10]
X-Spam: [F=0.6365217096; CM=0.500; MH=0.636(2015111312); S=0.200(2015072901)]
X-MAIL-FROM: <xxxxxxxxxxxx>

Content-Type: multipart/alternative;

Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64


Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64



Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=78361;
	creation-date="Fri, 13 Nov 2015 15:19:47 GMT";
	modification-date="Fri, 13 Nov 2015 15:19:47 GMT"
Content-ID: <image001.jpg@01D11DFC.D0CBB430>
Content-Transfer-Encoding: base64



Comment 9

3 years ago
Created attachment 8687337 [details]
Screenshot of hang

This is the compose window during the checkpoint that hangs.

Note that if I were to try to send the message without deleting the photo, the same thing would happen.


Comment 10

3 years ago
tlhackque, what you describe is a known issue. please see one of these bugs -

Comment 11

3 years ago
I am writing for myself, not the OP - though (obviously) I think it's the same issue despite his vague description.

There may be a common underlying issue with the listed bugs, but it's not clear from their symptoms.

My case is pretty straightforward - and I expect common.  Replying to an e-mail chain in INBOX.

165154 - I'm not saving as HTML
727324 - I do not have special characters in the mailbox name
764197 - May be close, but does not provide useful work-around.  "Copy into another application and paste into a new message" does not maintain the headers from the original message stream, which are needed for proper threading. Of course, the user is also obliged to copy the to, cc, bcc, subject and any attachments to the new message as well.
989621 - Copy and paste is not involved.  The original insert image is from a file, not drag and drop or paste.  Of course the image in the reply is a 'non-file uri' (cid:).
1029452 - Has nothing to do with e-mail signature

If the underlying issue is the same for all of these, and well-enough understood, consolidating all of these into a single bug report might be reasonable.

It's a frustrating issue.  Having to delete content when replying gets painful when there are a lot of images.  And the recipient of the reply doesn't get the images.  So has to find the older message if they are referenced in the reply.  When you make your correspondent work, the odds of a reply drop.

Thanks for the interest in this issue.
You need to log in before you can comment on or make changes to this bug.