642566 - Reply / Forward mail shows broken image icon in html signature

Status: RESOLVED DUPLICATE of bug 1251408

(Thunderbird :: Message Compose Window, defect)

Description

[u407471]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Red Hat/3.6.14-4.el6_0 Firefox/3.6.14
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Red Hat/3.1.8-4.el6_0 Lightning/1.0b2 Thunderbird/3.1.8

When replying to or forwarding a message the picture included in the html signature shows as broken in the compose window. Doubleclicking on it and simply press ok fixes it.(Path to file is correct)

Sending the mail as is with a broken image icon in the compose window shows the picture correctly both in the "Sent" folder and at the recipient. So this is just a problem with the compose window.

Creating a new mail works ok.

Reproducible: Always

Steps to Reproduce:
1. Reply to mail or forward mail using a html signature including a picture

Actual Results:  
Compose window shows a broken image icon where the picture should be.

Expected Results:  
Should show a picture as it does when creating a new mail.

Settings:
Start my reply above the quote
and place my signature below my reply (above the quote).

Comment 1

[Ludovic Hirlimann [:Usul]]

Is it the case with all messages ?

Can you save one of these messages in .eml format (ie File -> Save as ...) and come back to this web page and attach the .eml file to the bug using the add an attachment link above ? this will greatly help for analysis.

Comment 2

[u407471]

Attachment: email

Replying to this mail shows a broken image in my html signature.

Comment 3

[u407471]

I have tested and this problem seems to affect all my emails, (html, text, with or without attachments)

Comment 4

[u407471]

Replying to your email (shows broken picture as usual) but instead of sending it saving it to Drafts and then open it from there shows the picture again correctly

Comment 5

[u407471]

Attachment: Signature that doesn't work

This is an example of an signature that doesn't work.

Comment 6

[Ludovic Hirlimann [:Usul]]

Can you post a screenshot of the bad signature  (ie it works for me, or I'm not looking at the same thing you are)?

Comment 7

[u407471]

Attachment: Broken image when reply

Comment 8

[u407471]

Attachment: Doubleclick on the broken image

Comment 9

[u407471]

Attachment: After doubleclick and just click ok

Comment 10

[u407471]

This also affects TB 3.1.9 on windows with a similar html signature. Email sends and looks ok in sent and drafts. This only affects the compose window at the time you write the reply/forward. Creating a new mail is not affected by this bug. As you can see on the attachments I can simply click the broken image and choose ok and it displays properly before I send it. But I can just send it with a broken picture and it looks ok at the recipient.

Comment 11

[Joe Sabash [:JoeS1]]

In your sample sig:
src="file:///mnt/share/AlphaOne/Epost%20signaturer/alphaone_logo.png"
There is no complete path to the image.
src="file:///c:/mnt/share/AlphaOne/Epost%20signaturer/alphaone_logo.png"
Or wherever the image resides, should work OK

When you Doubleclick to restore the image view, this path must be somehow completed.

To prove this to yourself, after you doubleclick and the image is visible.
Edit>>select all, then insert>> html.
I think you will then see the complete path to the image is now there.

Comment 12

[Joe Sabash [:JoeS1]]

I see that you are using Linux
My testing was in windows, so those references might change.

Comment 13

[Joe Sabash [:JoeS1]]

Thinking about this further, your problem might be related to using the file:///
format. See http://kb.mozillazine.org/Links_to_local_pages_don%27t_work
IYou might try to use src="mnt/share/AlphaOne/Epost%20signaturer/alphaone_logo.png" avoiding the file uri altogether.

Comment 14

[u407471]

Using src="mnt/share/AlphaOne/Epost%20signaturer/alphaone_logo.png" does not work at all. You need to specify file:///. As as this only affects reply/forward and NOT when creating a new mail it has to be a bug unless TB does something special in these cases. And because the signature works ok when creating a new mail and it always sends correctly in all cases (new mail/reply/forward) (even thou it shows as broken when composing the reply/forward)it also leads me to believe this is a bug.

Comment 15

[Joe Sabash [:JoeS1]]

That may have been old info on the file url stuff.
Here is a chunk of a sig that works for me>
<img style="padding-top: 4px;" alt=""
 src="file:///D:/demogifs/mlogo2.gif" height="20"
 width="28">

Note that it does not include the "moz-do-not-send" attribute.

Comment 16

[u407471]

Removing the "moz-do-not-send" attribute solves the problem. So is that a deprecated attribute or ?

Comment 17

[Joe Sabash [:JoeS1]]

I'll have to go back and check what the original purpose was for "moz-do-not-send"
I believe it was to eliminate internalizing remote images for multiple forwarding of messages.
It works fine for maintaining a link to a remote image in a sig when="true".
Most likely, we are not properly evaluating the "false"" state in this instance.

Glad you got it working, in the meantime.

Comment 18

[rsx11m]

The intended use of that attribute is to prevent images from remote sources (i.e., http, https, or ftp URIs) to be attached to the message and thus to take up space in the message while they are publicly accessible anyway. For local URIs like "file:" not accessible outside the context of your machine, that attribute doesn't make sense.

Its value defaults to "false", thus providing it in an <img> tag shouldn't have any effect in theory. However, handling of the attribute has shown issues in the past and a couple of bugs should be pending on those.

Note that bug 637670 would disable the checkbox to prevent accidental setting of "moz-do-not-send" for URIs where it isn't useful, but that wouldn't have an impact on specifying it in a signature as you did.

My best guess is that placement of the signature between reply and quote may contribute that it's seen in such cases only, possibly due to some caching issue with the image presentation in the composition window.

Comment 19

[Jorg K (CEST = GMT+2)]

Forward duplicate to bug where this will be fixed.