This site will have limited functionality while we undergo maintenance to improve your experience. If an article doesn't solve your issue and you want to ask a question, we have our support community waiting to help you at @FirefoxSupport on Twitter and/r/firefox on Reddit.

Avatar for Username

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

This thread was archived. Please ask a new question if you need help.

Images not properly parsed/copied on mail copy/move from one mailbox to another (same IMAP server).

  • 3 replies
  • 3 have this problem
  • 1 view
  • Last reply by sunbeam906

sunbeam906
sunbeam906
more options

Hello everyone.

I've recently discovered this issue; not sure how long's it been there, yet here goes:

- let's say I receive an email with embedded images on my personal account's Inbox

- I reply to it, then I want to move/copy the emails to another mailbox's Inbox (e.g.: from Inbox of me@domain.com to Inbox of you@domain.com; again, same IMAP server)

- what happens next is the message is moved/copied, but when being downloaded for display the inline images don't show up (empty rectangles are shown instead).

See below:

1. Original message:

https://i.imgur.com/osDClAy.png

2. Copied/moved message:

https://i.imgur.com/FO4qc6c.png

I've installed an add-on called "Show All Body Parts" and both the original email in its location and the copy in the other Inbox show the same amount of attachments, but.. there is one attachment called "Part1.2.1" reported as a certain size, but dumped on disk is 0 KB ("Part1.1" contains the raw text message; "Part1.2.1" is the actual HTML message with the images linked/attached/inlined).

3. "Show All Body Parts" comparison:

- body parts of original message:

https://i.imgur.com/vMhPw1V.png

- sizes of the files saved to disk:

https://i.imgur.com/noTbxYL.png

- content of Part1.1 and Part1.2.1:

https://i.imgur.com/81wVJM3.png

- body parts of the copied message (as you can see, reported sizes are the same):

https://i.imgur.com/QinODxu.png

- sizes of the files saved on disk:

https://i.imgur.com/Sj7C7cw.png

- content of Part1.1 and Part1.2.1 (Part1.2.1 is 0 KB, therefore no HTML):

https://i.imgur.com/D2fMTP1.png

Same goes for all other image attachments, they are 0 in size. Something tells me TB doesn't copy anything on copy/move but the raw text message.

What else I tried was to disable/remove all add-ons; no change. Same behaviour. The only thing that actually works is exporting the message as .eml on disk and importing it in the other folder. Why that works and not drag-and-dropping (like in older versions of TB) that I don't know :(

Kindly consider this a BUG rather than a question.

Best regards, Bogdan

Hello everyone. I've recently discovered this issue; not sure how long's it been there, yet here goes: - let's say I receive an email with embedded images on my personal account's Inbox - I reply to it, then I want to move/copy the emails to another mailbox's Inbox (e.g.: from Inbox of me@domain.com to Inbox of you@domain.com; again, same IMAP server) - what happens next is the message is moved/copied, but when being downloaded for display the inline images don't show up (empty rectangles are shown instead). See below: 1. Original message: https://i.imgur.com/osDClAy.png 2. Copied/moved message: https://i.imgur.com/FO4qc6c.png I've installed an add-on called "Show All Body Parts" and both the original email in its location and the copy in the other Inbox show the same amount of attachments, but.. there is one attachment called "Part1.2.1" reported as a certain size, but dumped on disk is 0 KB ("Part1.1" contains the raw text message; "Part1.2.1" is the actual HTML message with the images linked/attached/inlined). 3. "Show All Body Parts" comparison: - body parts of original message: https://i.imgur.com/vMhPw1V.png - sizes of the files saved to disk: https://i.imgur.com/noTbxYL.png - content of Part1.1 and Part1.2.1: https://i.imgur.com/81wVJM3.png - body parts of the copied message (as you can see, reported sizes are the same): https://i.imgur.com/QinODxu.png - sizes of the files saved on disk: https://i.imgur.com/Sj7C7cw.png - content of Part1.1 and Part1.2.1 (Part1.2.1 is 0 KB, therefore no HTML): https://i.imgur.com/D2fMTP1.png Same goes for all other image attachments, they are 0 in size. Something tells me TB doesn't copy anything on copy/move but the raw text message. What else I tried was to disable/remove all add-ons; no change. Same behaviour. The only thing that actually works is exporting the message as .eml on disk and importing it in the other folder. Why that works and not drag-and-dropping (like in older versions of TB) that I don't know :( Kindly consider this a BUG rather than a question. Best regards, Bogdan

Chosen solution

Thanks for filing the bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1430480.

We have reproduced the problem and will be developing a fix in the next few weeks. My initial investigation showed that the problem doesn't happen on all IMAP servers, but I have a test server that also exposes the problem.

I believe that repairing the folder (right-click, Properties, Repair Folder) restores the message back to working order.

Read this answer in context 👍 1

All Replies (3)

christ1
christ1
  • Top 25 Contributor
more options

You may want to raise a new bug in Bugzilla. https://bugzilla.mozilla.org/

Jorg K
Jorg K
more options

Chosen Solution

Thanks for filing the bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1430480.

We have reproduced the problem and will be developing a fix in the next few weeks. My initial investigation showed that the problem doesn't happen on all IMAP servers, but I have a test server that also exposes the problem.

I believe that repairing the folder (right-click, Properties, Repair Folder) restores the message back to working order.

sunbeam906
sunbeam906 Question owner
more options

Hello.

Right-click -> Properties -> Repair Folder seems to solve it for the time being. However, I'd like this fixed (didn't happen with older builds) at your (plural) convenience.

Best regards, Bogdan