Closed Bug 1391732 Opened 7 years ago Closed 7 years ago

Embedded images do not appear in TB 52.3.0 when editing or addressing message to be sent

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: regner, Unassigned)

References

(
URL
)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170814072924

Steps to reproduce:

Inserted multiple images into a message in TB 52.3.0.  Images were displayed while composing.

Saved the message as a draft.  Images were displayed while message was unopened in the drafts folder.

Opened the message to edit it and the images were not displayed.

Tried Editing Message As New.  Images were displayed in the body.  Saved the message and images were displayed in the drafts folder.  Tried to Edit the draft message and the images were again not displayed.


Actual results:

I sent the message to myself.  Images were not displayed when addressing the message.  When received, the images were displayed in the message.


Expected results:

Images should be displayed when editing the message or when addressing it for sending.  This has always been the case in all prior versions of TB.
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #1)

Thanks Wayne -- just installed this morning and hadn't read the release notes. I set mail.compose.attach_http_images to True but the behavior remains the same.

This new handling of downloaded images essentially eliminates the ability to edit or position the image as desired within the message body.
Component: Untriaged → Composition
Product: Thunderbird → MailNews Core
Version: 52 Branch → 52
You must have upgraded from TB 45 since the behaviour hasn't changed since TB 52.2.1.

So you're saying that the images show when viewing the saved draft and when editing the draft as new, but not when using "edit draft". The code path for "edit as new" and "edit draft" are almost the same. Furthermore I cannot reproduce the problem in TB 52.3 or current Daily TB 57.

So there must be an add-on interfering. Please try with add-ons disabled, see Help menu. If that fixes the problem, try to find out which add-on it is that is causing the problem.

To diagnose it further, do this: Install the add-on ThunderHTMLedit (https://addons.mozilla.org/en-us/thunderbird/addon/thunderhtmledit/).

Create a draft with a very small image. Then edit this draft, the images don't show according to your report, switch to the HTML tab and paste the HTML you see into a comment there.

I bet you will see some
<img src="mailbox: ...> or <img src="imap: ...>. Or maybe I'm wrong, you should see <img src="data: ...>.

Or did you insert an image from the web, so something like <img src="http:// ...>?
(didn't notice you are the same person in SUMO)
URL: https://support.mozilla.org/questions...
(In reply to Jorg K (GMT+2) )

I upgraded from the immediately prior version, not 45.  I didn't experience this issue with any other the other versions from 45 up until 52.3.0.

I disabled all add-ons but the behavior was the same.

I downloaded and installed ThunderHTML edit.  The HTML tab showed this statement included in the HTML:

src="data:image/jpeg;filename=gmc15237020170815093300.jpg;base64,…[1]"
        moz-do-not-send="true" height="360" width="462" border="1"><br>
      <br>
      <img class="cartoon-image" alt=""

moz-do-not-send = "true" struck me as strange since the global preference mail.compose.attach_http_images had been changed to true (which I assume means this should have read moz-do-not-send = "false".

However, the message containing the image had been created before upgrading TO 52.3.0 and before changing mail.compose.attach_http_images to true.  So I edited the HTML in the original message for each of the images to read moz-do-not-send = "false".  After saving the message, the images were diplayed in drafts, when editing and when addressing.

To confirm that was the issue, I downloaded one of the images again into a new message.  The HTML read moz-do-not-send = "false" and the image was displayed in drafts, when editing and when addressing.

So the issue appears to be resolved by changing the global preference mail.compose.attach_http_images from false to true but that change will not correct any image displays in messages composed before that change unless each prior image's HTML is manually changed from moz-do-not-send = "true" to moz-do-not-send = "false".

Thanks for suggesting ThunderHTMLedit and helping me resolve this.  I'll copy your last comment and this one into my question on the Thunderbird support forum so others can reference it there as well.
You're mixing two issues here.

Firstly, mail.compose.attach_http_images only applies to images which are loaded from a http(s) source, so those which have
<img src="http:// ...>. Previously they were attached to messages automatically unless you chose not to for every individual image, effectively setting moz-do-not-send="true". This has changed to protect people on corporate intranets who might not want their images to be accidentally sent out. With mail.compose.attach_http_images set to "true", TB 52.x behaves like previous versions, downloads and attaches those images and sends them out.

The other class of image is the one stored directly in your message with <img src="data: ...> and a long base64 string follows which is typically shortened/hidden by utilities like ThunderHTMLedit.

Images placed with TB 52.x do not receive any moz-do-not-send attribute since the data is sent anyway. The behaviour of TB is slightly different depending on whether moz-do-not-send is set to "true" or "false" on those images, but it shouldn't affect whether they're shown after "edit draft".

I've created myself a message with embedded images with moz-do-not-send="true" and after editing the draft, the images still show.

I've also checked TB 45. When you embedded an image by pasting a bitmap and saving this as a draft, TB would not add moz-do-not-send="true". So drafts created with TB 45 will open without problem in TB 52.

I'm really at a loss to understand what's going on, let me summarise:
1) <img src="data: ...> should always display regardless of the moz-do-not-send value.
2) On embedded images which were originally pasted as bitmaps, so non-http-based images
   and non-file-based images, TB never placed a moz-do-not-send attribute.

Maybe you can do this experiment for me in TB 52:
- Create a draft, add an image. Save the draft, edit the draft.
- Check moz-do-not-send, it shouldn't be there. Now add moz-do-not-send="true". Save the draft and edit again.
- Check moz-do-not-send, it should be there as you set it, but the image should show.
(In reply to Jorg K (GMT+2) from comment #6)

I should have clarified in the initial post that the images in the document described were inserted from the web, not from files.  I think my explanation of the resolution is correct given images from an http source.

Sorry for the confusion.
I also want to reiterate that I have been creating and sending similar documents weekly for years.  I never ran into any issues doing so until 52.3.0.
Sorry, I still don' understand what went on here, especially
<img src="data:image/jpeg;filename=gmc15237020170815093300.jpg;base64,…[1]"
        moz-do-not-send="true" height="360" width="462" border="1">
should be displayed regardless of moz-do-not-send="true".

If you initially referenced a http-based image, and chose NOT to attach it, then we would have set moz-do-not-send="true", but then I don't understand the <img src="data: ...>. How did http: get converted to data:?

If you initially referenced a http-based image, and chose --- to attach it, then we would have set moz-do-not-send="false" and converted it to <img src="data: ...>. So where then did the moz-do-not-send="true" come from? And furthermore, despite moz-do-not-send="true" the image should have been displayed.

Can you reproduce the problem? Can you give me exact steps that will produce the problem, as in:
- Start a new e-mail composition.
- Insert and image from http: ..., select to [not?] attach the image to the message.
- Save the draft. What happens?
- Open the draft. What happens?

Let me give you two options:
Option 1:
- Start a new e-mail composition.
- Insert and image from http://www.jorgk.com/images/meflag.png, select to attach the image to the message.
- Save the draft. Image shows when viewing the draft in the Drafts folder.
- Open the draft. Image shows, it was converted to data: and moz-do-not-send="false"

Option 2a:
- Start a new e-mail composition.
- Insert and image from http://www.jorgk.com/images/meflag.png, select NOT to attach the image to the message.
- Save the draft. Image DOES NOT show viewing the draft in the Drafts folder due to blocked remote content.
- Open the draft. Image DOES NOT show.

Option 2b:
- Start a new e-mail composition.
- Insert and image from http://www.jorgk.com/images/meflag.png, select NOT to attach the image to the message.
- Save the draft. Image DOES NOT show viewing the draft in the Drafts folder due to blocked remote content.
  Unblock the remote content, so image shows.
- Open the draft. Image shows.

What you reported doesn't fall into those two use cases.
"If you initially referenced a http-based image, and chose NOT to attach it, then we would have set moz-do-not-send="true", but then I don't understand the <img src="data: ...>. How did http: get converted to data:?"

The original image was http-based. I used Copy Image to insert the image into the message. I'm not sure how the conversion to data occurred, but when the problem initially occurred I tried several options to see if I could get around it.  One of them was to copy the message(all images)into a word document where they did display, and then copy them back into a message where they didn't display.  I may have pulled the HTML from the message with images copied from the word document.

I did four tests.  Before each test I set the mail.compose.attach_http_images preference, then closed TB, reopened TB and composed the message, saved the message, then closed and reopened TB to check image displays.  In all 4 tests I used your image, either attached after savung to the desktop or copied into the message from http.

Test 1:  Preference set to true.  Image saved to desktop and then attached to message. Image displayed in drafts. Image not displayed when editing.  HTML as follows:

<html>
  <head>
    <meta http-equiv="content-type" content="text/html;
      charset=iso-8859-15">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <b><i><span style="font-size:10.0pt;line-height:107%;color:#002060"><o:p></o:p></span></i></b>
    <div class="moz-signature"> </div>
  </body>
</html>

Test 2:  Preference set to false.  Image attached to message.  Image displayed in Drafts.  Image not displayed while editing.  HTML as follows:

html>
  <head>
    <meta http-equiv="content-type" content="text/html;
      charset=iso-8859-15">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-signature">
      <meta http-equiv="Content-Type" content="text/html;
        charset=iso-8859-15">
      <meta name="ProgId" content="Word.Document">
      <meta name="Generator" content="Microsoft Word 15">
      <meta name="Originator" content="Microsoft Word 15">
      <link rel="File-List"
        href="RDE%20Email%20Signature_files/filelist.xml">

Test 3:  Preference set to true.  Image copied from http into message.  Image displayed in drafts.  Image displayed while editing.  HTMl as follows:

<html>
  <head>
    <meta http-equiv="content-type" content="text/html;
      charset=iso-8859-15">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div align="center"><img
src="data:image/png;filename=meflag.png;base64,…[1]"
        alt="http://www.jorgk.com/images/meflag.png" class="transparent"></div>
    <br>
    <div class="moz-signature">
      <meta http-equiv="Content-Type" content="text/html;
        charset=iso-8859-15">
      <meta name="ProgId" content="Word.Document">
      <meta name="Generator" content="Microsoft Word 15">
      <meta name="Originator" content="Microsoft Word 15">
      <link rel="File-List"
        href="RDE%20Email%20Signature_files/filelist.xml">

Test 4: Preference set to false.  Image copied from http into message.  Image displayed in Drafts.  Image not displayed while editing.  HTML as follows:

<html>
  <head>
    <meta http-equiv="content-type" content="text/html;
      charset=iso-8859-15">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-signature">
      <meta http-equiv="Content-Type" content="text/html;
        charset=iso-8859-15">
      <meta name="ProgId" content="Word.Document">
      <meta name="Generator" content="Microsoft Word 15">
      <meta name="Originator" content="Microsoft Word 15">
      <link rel="File-List"
        href="RDE%20Email%20Signature_files/filelist.xml">
      <!--[if gte mso 9]><xml>
Thanks for testing, but I'm still confused (and I'm one on the lead developers here).

(In reply to BirdieBob from comment #10)
> In all 4 tests I used your image, either attached
> after saving to the desktop or copied into the message from http.
OK, so you save the image to the desktop as a file, right?

> Test 1:  Preference set to true.  Image saved to desktop and then attached
> to message. Image displayed in drafts. Image not displayed when editing. 
> HTML as follows:
> 
> <html>
>   <head>
>     <meta http-equiv="content-type" content="text/html;
>       charset=iso-8859-15">
>   </head>
>   <body text="#000000" bgcolor="#FFFFFF">
>     <br>
>     <b><i><span
> style="font-size:10.0pt;line-height:107%;color:#002060"><o:p></o:p></span></
> i></b>
>     <div class="moz-signature"> </div>
>   </body>
> </html>
What do you mean by attached? Drag it into the attachment area? Not embed the image? The HTML you're showing is basically empty, no image embedded. Sure, when saving the draft the image will show as inline attachment under the message. If you edit the draft, the image will show again in the attachment area above. Since it's not embedded, it's not show in the message body.

> Test 2:  Preference set to false.  Image attached to message.  Image
> displayed in Drafts.  Image not displayed while editing.  HTML as follows:
Same as test 1.

> Test 3:  Preference set to true.  Image copied from http into message. 
> Image displayed in drafts.  Image displayed while editing.  HTML as follows:
> 
> <html>
>   <head>
>     <meta http-equiv="content-type" content="text/html;
>       charset=iso-8859-15">
>   </head>
>   <body text="#000000" bgcolor="#FFFFFF">
>     <div align="center"><img
> src="data:image/png;filename=meflag.png;base64,…[1]" <====== Here!
>         alt="http://www.jorgk.com/images/meflag.png"
> class="transparent"></div>
>     <br>
>     <div class="moz-signature">
>       <meta http-equiv="Content-Type" content="text/html;
>         charset=iso-8859-15">
>       <meta name="ProgId" content="Word.Document">
>       <meta name="Generator" content="Microsoft Word 15">
>       <meta name="Originator" content="Microsoft Word 15">
>       <link rel="File-List"
>         href="RDE%20Email%20Signature_files/filelist.xml">
Yes, the image is there in the message as data: URL where indicated. 

I don't know what you mean by "copy". I thought you use the Thunderbird "Insert > Image" function and paste:
http://www.jorgk.com/images/meflag.png
But apparently you visit the website, and "Copy Image" and then paste into the composition. That inserts a link to the image, but since your preference is set to true, upon save, the image is downloaded, and when you open the draft again, your see the data: URL. That works as expected.

> Test 4: Preference set to false.  Image copied from http into message. 
> Image displayed in Drafts.  Image not displayed while editing.  HTML as
> follows:
> 
> <html>
>   <head>
>     <meta http-equiv="content-type" content="text/html;
>       charset=iso-8859-15">
>   </head>
>   <body text="#000000" bgcolor="#FFFFFF">
>     <br>
>     <div class="moz-signature">
>       <meta http-equiv="Content-Type" content="text/html;
>         charset=iso-8859-15">
>       <meta name="ProgId" content="Word.Document">
>       <meta name="Generator" content="Microsoft Word 15">
>       <meta name="Originator" content="Microsoft Word 15">
>       <link rel="File-List"
>         href="RDE%20Email%20Signature_files/filelist.xml">
>       <!--[if gte mso 9]><xml>
This message doesn't contain any image.

Maybe this case 4 is where the problem lies. With the preference set to false, Thunderbird doesn't download the image. So in the drafts, it's usually blocked. When you unblock it, or you have the privacy option set not to block, you can see the image. It should subsequently also show when you edit the draft again, but again, in the HTML pasted above, there is no image anywhere.
(In reply to jorg K from comment #11)

See inserted answers under your comments.

> In all 4 tests I used your image, either attached
> after saving to the desktop or copied into the message from http.
OK, so you save the image to the desktop as a file, right?

    In the two tests of an attached image, I saved the image to the desktop as a file, then attached it to the message.       After changing the preference. I saved the image again and attached that to another message.  For the http tests, the image was copied from the web into the messages.

> Test 1:  Preference set to true.  Image saved to desktop and then attached
> to message. Image displayed in drafts. Image not displayed when editing. 
> HTML as follows:
> 
> <html>
>   <head>
>     <meta http-equiv="content-type" content="text/html;
>       charset=iso-8859-15">
>   </head>
>   <body text="#000000" bgcolor="#FFFFFF">
>     <br>
>     <b><i><span
> style="font-size:10.0pt;line-height:107%;color:#002060"><o:p></o:p></span></
> i></b>
>     <div class="moz-signature"> </div>
>   </body>
> </html>
What do you mean by attached? Drag it into the attachment area? Not embed the image? The HTML you're showing is basically empty, no image embedded. Sure, when saving the draft the image will show as inline attachment under the message. If you edit the draft, the image will show again in the attachment area above. Since it's not embedded, it's not show in the message body.

       The image is saved to the desktop (separately for each preference choice of true or falseI.  In TB, I click Write then Attach, navigate to the saved image on the desktop and select it.  The image is then an attachment and not embedded.

> Test 2:  Preference set to false.  Image attached to message.  Image
> displayed in Drafts.  Image not displayed while editing.  HTML as follows:
Same as test 1.

> Test 3:  Preference set to true.  Image copied from http into message. 
> Image displayed in drafts.  Image displayed while editing.  HTML as follows:
> 
> <html>
>   <head>
>     <meta http-equiv="content-type" content="text/html;
>       charset=iso-8859-15">
>   </head>
>   <body text="#000000" bgcolor="#FFFFFF">
>     <div align="center"><img
> src="data:image/png;filename=meflag.png;base64,…[1]" <====== Here!
>         alt="http://www.jorgk.com/images/meflag.png"
> class="transparent"></div>
>     <br>
>     <div class="moz-signature">
>       <meta http-equiv="Content-Type" content="text/html;
>         charset=iso-8859-15">
>       <meta name="ProgId" content="Word.Document">
>       <meta name="Generator" content="Microsoft Word 15">
>       <meta name="Originator" content="Microsoft Word 15">
>       <link rel="File-List"
>         href="RDE%20Email%20Signature_files/filelist.xml">
Yes, the image is there in the message as data: URL where indicated. 

I don't know what you mean by "copy". I thought you use the Thunderbird "Insert > Image" function and paste:
http://www.jorgk.com/images/meflag.png

     No, I use Copy Image to copy the image from the website and paste it into the message body, as you describe below.

But apparently you visit the website, and "Copy Image" and then paste into the composition. That inserts a link to the image, but since your preference is set to true, upon save, the image is downloaded, and when you open the draft again, your see the data: URL. That works as expected.

> Test 4: Preference set to false.  Image copied from http into message. 
> Image displayed in Drafts.  Image not displayed while editing.  HTML as
> follows:
> 
> <html>
>   <head>
>     <meta http-equiv="content-type" content="text/html;
>       charset=iso-8859-15">
>   </head>
>   <body text="#000000" bgcolor="#FFFFFF">
>     <br>
>     <div class="moz-signature">
>       <meta http-equiv="Content-Type" content="text/html;
>         charset=iso-8859-15">
>       <meta name="ProgId" content="Word.Document">
>       <meta name="Generator" content="Microsoft Word 15">
>       <meta name="Originator" content="Microsoft Word 15">
>       <link rel="File-List"
>         href="RDE%20Email%20Signature_files/filelist.xml">
>       <!--[if gte mso 9]><xml>
This message doesn't contain any image.

Maybe this case 4 is where the problem lies. With the preference set to false, Thunderbird doesn't download the image. So in the drafts, it's usually blocked. When you unblock it, or you have the privacy option set not to block, you can see the image. It should subsequently also show when you edit the draft again, but again, in the HTML pasted above, there is no image anywhere.

         I think case 4 is the issue.  With the preference set to false (by default) the image is not downloaded and the link to the image is blocked.  I know you've said this treatment has been in place since 45, but I never experienced it until 52.3.0 although I've used this same approach to create these messages through all interim versions.
(In reply to BirdieBob from comment #12)
>          I think case 4 is the issue.  With the preference set to false (by
> default) the image is not downloaded and the link to the image is blocked.
Right.

> I know you've said this treatment has been in place since 45, but I never
> experienced it until 52.3.0 although I've used this same approach to create
> these messages through all interim versions.
Blocking of remote images exists since TB 38 and even earlier.

In TB 52 we've changed the way image from files and images from http-resources are treated. Now, by default, embedded images are not downloaded and attached to the message any more. So now they usually will be blocked when viewing the draft or editing it again, unless unblocked in some way, either by unblocking images for the message individually, or per site/URL/origin or in general. My experiments have show that once the image is unblocked when showing the draft, it is also unblocked when the draft is edited again. I'd be happy to see a combination of factors where that is not the case.

Repeating: In TB 52 the downloading policy for http-based images has changed, so when these images are copied, which inserts, for example, <img src=http://www.jorgk.com/images/meflag.png">, you can get into image-blocking situations which didn't occur before.

My personal advice is to not copy but drag the image into the composition, since that always happens as bitmap with no chance to lose the image.

I think we've come a little closer to the truth about what caused your problems. I'd still like to see a case where the image shows when viewing the draft but doesn't show when editing the draft again.
Thanks and I understand what you're saying.  If the default for mail.compose.attach_http_images was changed to false in 52.3.0, I can understand the issue appearing then.  But if it has been that way for the length of time you say, I'm at a loss to explain why it happened only with 52.3.0.  But for now, changing that preference to true has resolved my issue.

I will try dragging the images into the message rather than copying.  If I run into a situation where the image appears in drafts and doesn't appear when editing (if the image was copied or dragged into the message) I will post that instance back here for you.
Thanks. By dragging you create a data: URL immediately, copying creates a reference (link in a way), that can cause problems later unless you automatically attach.

I'll close this for now, but feel free to come back and report more problems.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.