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

Lolu chungechunge lwabekwa kunqolobane. Uyacelwa ubuze umbuzo omusha uma udinga usizo.

Embedded images in TB 52.3.0 don't display when editing message

  • 3 uphendule
  • 1 inale nkinga
  • 4 views
  • Igcine ukuphendulwa ngu BirdieBob

more options

After updating to TB 52.3.0 this morning, embedded images within a message do not appear when editing or addressing a message. When saved as a draft, the images are displayed. Sending the message to myself, the images were not displayed when addressing but were displayed upon receipt.

I found in the release notes that the handling of downloaded images has been changed. The notes state that the global preference for mail.compose.attach_http_images can be changed. I reset that global preference to True but there was no change in how the images are displayed.

The effect of this change is to essentially eliminate the ability to edit or position an image (that you can't see) within the body of the message. I've reported this as a bug but if anyone has any suggestions to offer, please pass them on.

After updating to TB 52.3.0 this morning, embedded images within a message do not appear when editing or addressing a message. When saved as a draft, the images are displayed. Sending the message to myself, the images were not displayed when addressing but were displayed upon receipt. I found in the release notes that the handling of downloaded images has been changed. The notes state that the global preference for mail.compose.attach_http_images can be changed. I reset that global preference to True but there was no change in how the images are displayed. The effect of this change is to essentially eliminate the ability to edit or position an image (that you can't see) within the body of the message. I've reported this as a bug but if anyone has any suggestions to offer, please pass them on.

Isisombululo esikhethiwe

This issue was resolved with help from jorg K through the Bugzilla website. I'm posting his comment and my final reply here for others to reference.

BirdieBob edit for clarification: The images described in the document in question were inserted from the web, not from existing files. I should have stated that in the initial post but did not. The "moz-do-not-send" settings apply to images from http sources, not to images from files.

Comment from Jorg K (GMT+2)

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 or . Or maybe I'm wrong, you should see .

Or did you insert an image from the web, so something like ?

(BirdieBob 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">

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 t he 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.

Funda le mpendulo ngokuhambisana nalesi sihloko 👍 0

All Replies (3)

more options
more options

As I mentioned in Bugzilla, changing the global preference for mail.compose.attach_http_images to True (as suggested in the release notes) had no effect on image display.

more options

Isisombululo Esikhethiwe

This issue was resolved with help from jorg K through the Bugzilla website. I'm posting his comment and my final reply here for others to reference.

BirdieBob edit for clarification: The images described in the document in question were inserted from the web, not from existing files. I should have stated that in the initial post but did not. The "moz-do-not-send" settings apply to images from http sources, not to images from files.

Comment from Jorg K (GMT+2)

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 or . Or maybe I'm wrong, you should see .

Or did you insert an image from the web, so something like ?

(BirdieBob 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">

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 t he 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.

Okulungisiwe ngu BirdieBob