1699057 - Sending message with attachment is stuck

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Marek Sajner]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0

Steps to reproduce:

Create new email message, or forward the existing message, have some attachments included or added, edit the body of the message and have the message sent.

Actual results:

When email message is to send, the message "Creating messge..." appears and stays hanging on the screen.

Expected results:

Email message is not sent.

Comment 1

[Ping Chen [:rnons] (away)]

(In reply to Marek Sajner from comment #0)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0

Steps to reproduce:

Create new email message, or forward the existing message, have some attachments included or added, edit the body of the message and have the message sent.

Is it possible you can upload one of the existing messages with attachments so I can reproduce? Thanks

Comment 2

[Marek Sajner]

Actually I think it is attachment-type independent. I observed it on PDFs, DOCx as well as JPGs.
But, the behavior is somewhat inconsistent. Most of the time the message is sent without a problem. Sometimes it stucks with that message.
I am unable to reproduce it solidly.
Definitely relates to recent attachment-handling changes introduced I believe in 86/87? I never observed this problem on earlier releases.

Comment 3

[Calum Mackay]

I believe I'm seeing this.

For me, the problem is not attachments in general, but only with forwarding email (as attachment).

Currently on Daily 0413. MacOS 10.15.7 (19H524)

I can reproduce it as far back as 0401; further back, and I start to hit Profile version change warnings.

symptom: when sending with an attachment that is an email (e.g. forwarding), on pressing "send" the status popup says "Creating mail message…", and stays like that indefinitely.

It seems to relate to which account supplies the message being forwarded as an attachment.

Some points:

• all my accounts use IMAP/SSL

• the same sending account, with the same recipient, works fine when sending with no attachment.

• the same sending account, with the same recipient, works fine when sending with a file attachment, dragged from my Desktop.

• the same sending account, with the same recipient, works fine when sending with an email that is dragged to it from another account (from another TB window), even one from the same IMAP server

• a different sending account, with a different recipient, works fine when sending with an email from that second account, whether this sending account is on the same IMAP server, or a different one.

• a different sending account, with a different recipient, shows the same problem, when the email to be forwarded is dragged from the first account window. i.e. the problem relates to the email that is being forwarded as an attachment, and is independent of sending account & recipient.

• the problem occurs when such a mail is forwarded by dragging, or by Ctrl-L forward.

• the problem occurs for every single message that I try to forward, when that message is stored in a particular IMAP account.

• messages stored in other IMAP accounts, including on the same IMAP server as above, may be forwarded fine, even with the same sending acocunt & recipient as above.

• I have two accounts from the same IMAP server; only one account's stored messages show this problem.

• forwarding inline works fine; the problem only occurs when forwarding as an attachment. So it's not the /content/ of the forwarded messaage that can't be accessed (and I can see it on screen, in any case)

• sometimes, rather than it hanging, I get an error:

Send Message Error
Sending of the message failed
There was an error attaching <subject>.eml. Please check that you have access to the file

this when Ctrl-L forwarding an email that is currently visible.

This difference here seems to be where the message being forwarded is located, within this single account:

if the message is in my INBOX, I get the above error, when trying to forward it

if I then move the message from INBOX, to a folder (same IMAP account), then try to forward it from that folder, I get the "Creating mail message…" behaviour, with no error.

In the error case, Error Console shows:

01:19:40.259 mailnews.send: Failed to fetch attachment: name=blah.eml, url=imap-message://[e-mail]/INBOX#879146 MimePart.jsm:160:29
getEncodedBodyString resource:///modules/MimePart.jsm:160

01:19:40.259 mailnews.send:
Exception { name: "", message: "Failed to fetch attachment", result: 2153066778, filename: "resource:///modules/MimePart.jsm", lineNumber: 163, columnNumber: 0, data: XPCWrappedNative_NoHelper, stack: "getEncodedBodyString@resource:///modules/MimePart.jsm:163:26\n", location: XPCWrappedNative_NoHelper }
columnNumber: 0
data: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), url: Getter & Setter, name: Getter & Setter, … }
filename: "resource:///modules/MimePart.jsm"
lineNumber: 163
location: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), filename: Getter, name: Getter, … }
message: "Failed to fetch attachment"
name: ""
result: 2153066778
stack: "getEncodedBodyString@resource:///modules/MimePart.jsm:163:26\n"
<prototype>: ExceptionPrototype { toString: toString(), name: Getter, message: Getter, … }
MessageSend.jsm:122:27

01:19:40.261 mailnews.send: Sending failed; There was an error attaching blah.eml. Please check that you have access to the file., exitCode=2153066778, originalMsgURI=imap-message://[e-mail]/INBOX#879146 MessageSend.jsm:320:27
fail resource:///modules/MessageSend.jsm:320
createAndSendMessage resource:///modules/MessageSend.jsm:130

Comment 4

[Calum Mackay]

Marek: do you see this problem when sending a new message, with a regular (non-email) file attachment,. e.g. from the Desktop?

I only see this when forwarding an email as an attachment; but otherwise it sounds similar.

Comment 5

[Calum Mackay]

One more odd point:

• if I move an email that I'm unable to forward, to a different account on the same IMAP server, then the problem goes away, and I can forward it fine, even as the first account sender.

Comment 6

[Ping Chen [:rnons] (away)]

Attachment: Bug 1699057 - Use nsIMsgMessageService.streamMessage to get msg attachment content. r=mkmelin

Comment 7

[Magnus Melin [:mkmelin]]

Does your username or password contain non-ascii characters?

Comment 8

[Ping Chen [:rnons] (away)]

I can reproduce with an ascii gmail address. But another of my gmail works fine.

Comment 9

[Magnus Melin [:mkmelin]]

Any specials in there, that would be different when put through url encoding?

Comment 10

[Marek Sajner]

(In reply to Calum Mackay from comment #4)

Marek: do you see this problem when sending a new message, with a regular (non-email) file attachment,. e.g. from the Desktop?

I only see this when forwarding an email as an attachment; but otherwise it sounds similar.

I am now at 88.0b2 and have not seen the issue since I reported actually, but it does not mean it was fixes as I may see from other comments.

Comment 11

[Ping Chen [:rnons] (away)]

(In reply to Magnus Melin [:mkmelin] from comment #9)

Any specials in there, that would be different when put through url encoding?

I don't think so, I printed out the basic auth token, and used atob to decode it, nothing special. I have the same two gmail accounts on another computer, the situation is the reverse. The mail address that worked in comment 8 doesn't work now. I guess it's related to how IMAP server associate the request url to the mail account, basic auth is not really used by IMAP server.

Comment 12

[Magnus Melin [:mkmelin]]

John, IIRC you were involved with some bugs for multiple auth setups earlier. Any ideas?

Comment 13

[John Bieling (:TbSync)]

The only area where I was involved is calendar and the issues I had where cookie related. If two connections to the same server but different accounts where made (url.spec being identical), one of them failed because it was using the others auth cookie. The solution was to enforce a unique userContextId per principal. See bug 1544596.

https://searchfox.org/comm-central/rev/33fdb2afed98b1241830e418e9107e36d125e210/calendar/base/modules/utils/calProviderUtils.jsm#62
https://searchfox.org/comm-central/rev/33fdb2afed98b1241830e418e9107e36d125e210/calendar/base/modules/utils/calProviderUtils.jsm#71

Does that help?

Comment 14

[Calum Mackay]

(In reply to Magnus Melin [:mkmelin] from comment #7)

Does your username or password contain non-ascii characters?

No, plain ASCII.

I checked my IMAP server (dovecot) logs: no sign of any issues there. No signs of failed login.

Comment 15

[Calum Mackay]

It looks like I last successfully forwarded an email, stored in that account, on 15th February. I don't do that very often, unfortunately.

Of course, that doesn't mean a TB change since then; there might have been some external change, that triggered a latent code issue in TB.

Comment 16

[Magnus Melin [:mkmelin]]

Ping: Maybe an IMAP log would say what's actually wrong. https://wiki.mozilla.org/MailNews:Logging

Comment 17

[Ping Chen [:rnons] (away)]

There is no IMAP log in this case, because fetch/NetUtil downloads the URL directly. I updated the patch to use nsIMsgMessageService.streamMessage, which can use local copy without network request.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/4dd0c650fcb8
Use nsIMsgMessageService.streamMessage to get msg attachment content. r=mkmelin

Comment 19

[Calum Mackay]

Confirmed fixed in Daily 0415.

Both my cases: INBOX (with error) and folder (blocks, no error), now both fine.

thanks very much indeed, Ping.

Comment 20

[Calum Mackay]

[Should I change to VERIFIED?]