Closed Bug 1699057 Opened 4 years ago Closed 4 years ago

Sending message with attachment is stuck

Categories

(Thunderbird :: Message Compose Window, defect)

Thunderbird 87
defect

Tracking

(thunderbird_esr78 unaffected, thunderbird88 affected)

RESOLVED FIXED
89 Branch
Tracking Status
thunderbird_esr78 --- unaffected
thunderbird88 --- affected

People

(Reporter: msajner, Assigned: rnons)

References

(Regression)

Details

Attachments

(1 file)

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.

Flags: needinfo?(remotenonsense)

(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

Flags: needinfo?(remotenonsense) → needinfo?(msajner)

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.

Flags: needinfo?(msajner)

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://xxx@cdmnet.org/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://xxx@cdmnet.org/INBOX#879146 MessageSend.jsm:320:27
fail resource:///modules/MessageSend.jsm:320
createAndSendMessage resource:///modules/MessageSend.jsm:130

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.

Flags: needinfo?(msajner)
Status: UNCONFIRMED → NEW
Ever confirmed: true

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.

Assignee: nobody → remotenonsense
Status: NEW → ASSIGNED

Does your username or password contain non-ascii characters?

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

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

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

Flags: needinfo?(msajner)

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

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

Flags: needinfo?(john)

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?

Flags: needinfo?(john)

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

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.

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

Attachment #9215717 - Attachment description: Bug 1699057 - Use NetUtil instead of fetch to download attachments. r=mkmelin → Bug 1699057 - Use nsIMsgMessageService.streamMessage to get msg attachment content. r=mkmelin

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.

Regressed by: 1211292
Target Milestone: --- → 89 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/4dd0c650fcb8
Use nsIMsgMessageService.streamMessage to get msg attachment content. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED

Confirmed fixed in Daily 0415.

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

thanks very much indeed, Ping.

[Should I change to VERIFIED?]

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: