1334549 - Sending message failed when replying to an email - Status: Attaching - Progress bar 100% green but never complete the process

Status: RESOLVED WORKSFORME

(Thunderbird :: Untriaged, defect)

Description

[Richard Leger]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Steps to reproduce:

User hit reply to a message, edit few lines without adding any file in attachment and press Send button.

Environment: Win7 Pro x64, MS AV, TB 45.6, IMAP account, message not kept on computer, IMAP server on the same 1GB LAN as client computer.


Actual results:

Sending Message prompt appears showing status:Attaching, progress bar become 100% green but process never ends, message is not sent. User can press Cancel button and when try again it is sent fine.


Expected results:

Msg shall be send right away during first attempt.

Comment 1

[Jorg K (CEST = GMT+2)]

Maybe a network problem since it was sent on the second attempt. Does this happen frequently? Is this reproducible?

Comment 2

[Richard Leger]

It is very frequent according to multiple users. Not reproctuctable at will, seems random. To my opinion it may be linked to the fact account are not synched by default (msg not kept on computer).

Maybe images are beeing downloaded from the server while being sent andbthat cause the issue? Or TB  may not be looking at right cache location to attach images from reply-to msg signature.

I don't think it is a network issue that would not affect only TB if that was the case. I seems to recall similar bug affecting TB 52 or 53 that was recently fixed but cannot hold hand on it anymore for some reason. Maybe fix could be backported?

Comment 3

[Jorg K (CEST = GMT+2)]

Try TB 52 beta from https://www.mozilla.org/en-US/thunderbird/channel/. We have completely reworked to compose pipeline to avoid any "attaching" issues. With TB 52 coming out in six weeks, we won't touch TB 45 any more.

Comment 4

[Richard Leger]

End-users not willing to try 52 beta afraid it might cause more harm ;-) They prefer wait for stable...

What I'll do is install 52 beta on my machine (not exactly same env win7 with legacy drive) and see if I can reproduce the bug. If I find any I will report them.

Would beta version automatically update to stable once out or would it remain on the beta channel and only update to futur beta version?

Comment 5

[Jorg K (CEST = GMT+2)]

You remain on the beta channel, so you need manual intervention to go to the ESR channel once TB 52 ESR is released.

Comment 6

[Richard Leger]

I have installed version 52beta on my computer in a "eat your own dog food" attempt! I usually connect towards Internet to the IMAP server would that impact the test? Performance of 52beta does not always seems very good at startup... very long to start :-) Will report back if notice this bug anyhow... not exactly same configuration than users encountering the issue bug but close enough :-) None of them want to test beta version :-)

Comment 7

[Richard Leger]

Wayne, you can clear the needinfo flag on this bug, it was set by mistake... sorry for inconvenience... don't fine a way to cancel it... :-)

Comment 8

[Richard Leger]

Additional feedback:

One users did no longer encounter this issue since I set the option "Keep message for this account on this computer" option in IMAP account settings for about a month now. All other users having this option disabled except the following one...

Another one on the same network with same setup for which I set this option only partially "Synchronise the most recent" 30days and "Don't download msg older than" 50kB has reported the issue as well mostly when taking a long time to edit a response... e.g starting... then doing something else, then looking for attachments, adding them to the msg but not sending immediately... increasing delay in sending action from the user... and then when finally ready and trying to send msg the same issue as described in this bug occurs.

Basically this issue seems more likely to occurs when local cache is not used and when users take quite sometime to edit response prior hitting the Send button...

Don't know if that help but I thought it was worth mentioning...

At this stage we haven't been able to identified specific recipients or msg for which this issue is more likely to occur... it remain, as it seems, totally random.

All users using TB 45.8 at the moment...

Comment 9

[Wayne Mery (:wsmwk)]

How is the 53 beta for you lately?

Comment 10

[DaveLaw]

I believe this problem is not confined to IMAP:
I (and very many others) are getting it with SMTP.
This has apparently been going on for years. See following Mozallazine Posting:
http://forums.mozillazine.org/viewtopic.php?f=39&t=2459519
>
I have an old Installation (v45.8.0) under Windows XP which works fine.
v52.1.0 and predecessors (Windows 8 & 10) stopped working for me about a year ago.

Comment 11

[DaveLaw]

Attachment: ThunderBird_Bug_1334549_Sending.png

It just sits there for ages saying "Delivering mail..." & then times out.

Comment 12

[Wayne Mery (:wsmwk)]

(In reply to DaveLaw from comment #11)
> Created attachment 8866170 [details]
> ThunderBird_Bug_1334549_Sending.png
> 
> It just sits there for ages saying "Delivering mail..." & then times out.

Does it reproduce with Windows and Thunderbird in safe mode?
Start *Windows'* safe mode with networking enabled
- XP http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/boot_failsafe.mspx
Still In Windows safe mode, start thunderbird in safe mode
- https://support.mozilla.org/kb/safe-mode-thunderbird

Does problem go away?

Comment 13

[DaveLaw]

Sorry, should have got back to you on this one too.
Seems ok now.
I think I can put a date on it: between 2017.04.10 and 2017.05.10.
Sorry, no record of which version fixed it, I just assumed the Beta which Jörg Knobloch mentioned in Comment #3 had percolated through to the release channel.
>
Currently running v52.2.1 & everything is Hunky Dory.
Thank you.

Comment 14

[Jorg K (CEST = GMT+2)]

Thanks for letting us know. Richard isn't answering, so let's close this for now.

Comment 15

[Richard Leger]

I can confirm that upgrading to 52 stable version seems to have sorted the issue.

Comment 16

[Wayne Mery (:wsmwk)]

Thanks for the update

Comment 17

[DaveLaw]

Attachment: v52.3.0_Bug_1334549_SendError.png

The Problem seems to be still there after all.
Maybe the problem is confined to Windows 10?
v52.2.1 & v 52.3.0 both failed under Windows 10 Home.
v52.2.1 under Windows XP Pro works fine (& always has done).

Comment 19

[ISHIKAWA, Chiaki]

(In reply to Richard Leger from comment #8)

Additional feedback:

One users did no longer encounter this issue since I set the option "Keep
message for this account on this computer" option in IMAP account settings
for about a month now. All other users having this option disabled except
the following one...

Another one on the same network with same setup for which I set this option
only partially "Synchronise the most recent" 30days and "Don't download msg
older than" 50kB has reported the issue as well mostly when taking a long
time to edit a response... e.g starting... then doing something else, then
looking for attachments, adding them to the msg but not sending
immediately... increasing delay in sending action from the user... and then
when finally ready and trying to send msg the same issue as described in
this bug occurs.

Basically this issue seems more likely to occurs when local cache is not
used and when users take quite sometime to edit response prior hitting the
Send button...

While a user thinks that the messages, say, recent messages i the last 30 days, are in the local cache,
there may be a TB bug that does not properly recognize the proper messages.
I can not find the bugzilla entry immediately, but there WAS a bug that
delete newer messages by mistake when the user sets the feature to delete messages OLDER than certain days on POP3 server.
TB does not properly "sort" the message list and before the deletion begins, and delete the messages from the end of the list and thus it deletes new messages that should not be deleted. (Now I am not sure how TB decides to stop deletion when the list is not sorted properly.)

If similar function is used to pick up the candidates for caching messages younger than 30 days, then the cache may actually contain older messages and may not contain the desired set.

Don't know if that help but I thought it was worth mentioning...

At this stage we haven't been able to identified specific recipients or msg
for which this issue is more likely to occur... it remain, as it seems,
totally random.

All users using TB 45.8 at the moment...

Well, if the user thinks the message or whatever is in the cache, but not so, then the added operation of copying the message(s) may slow down the operation as experienced by the user with the false sense of caching.