270380 - Local image files in HTML signature file on top don't get attached in replies

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect)

Description

[Rene L.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0

I am using Thunderbird Version 0.9 (20041103).

I want to send HTML emails with an .html signature file.
In this HTML signature file are some local image files referenced by <img
src="file:///path_to_local_image_file">.

These signature images are displayed correctly while composing, but if I save
the mail as a draft for example, the signature source code was changed:
moz-do-not-send="true" was inserted, so the images will not be attached to the
outgoing mail.

I have to remove the moz-do-not-send attribute from each signature image in each
mail by hand if I want to send them attached.

Reproducible: Always
Steps to Reproduce:
1. Include an HTML signature file with local image files: i.e. <img
src="file:///C:/test.gif">
2. Write a new message including this signature file
3. Look at the modified source code of the message: <img moz-do-not-send="true"
src="file:///C:/test.gif">
Actual Results:  
<img moz-do-not-send="true" src="file:///C:/test.gif">

Expected Results:  
<img src="file:///C:/test.gif">
or
<img moz-do-not-send="false" src="file:///C:/test.gif">

Comment 1

[Mike Cowperthwaite]

I can't reproduce this symptom with TB 0.9, Win2K.  Please attach a copy of the 
sig file to this bug (or paste it in to a comment here, if it's not too big).

Comment 2

[Rene L.]

Attachment: HTML signature with local image file references

HTML signature file contains two local image file references and one remote
image file reference.
All <img> tags are changed by Thunderbird with moz-do-not-send="true"
attributes upon each use (new message, answer, forward).

Comment 3

[Mike Cowperthwaite]

I tried using your sig, and all three images were attached to the bug.
(Incidentally, the expected results are something of the form
  <img src="cid:somethingsomething">
The cid: "protocol" is used to refer to a different part of the message.)

Are you running with any extensions that might be doing this automatically?

Bug 176416 is about people wanting the behavior you're seeing...

Comment 4

[Rene L.]

(In reply to comment #3)

Interesting, even the remote image reference?
Then maybe Bug 176416 is applicable to your Thunderbird, too.

I know the <img src="cid:attachment_reference"> attribute values, Thunderbird
sets them for mail images which get sent properly attached.

I came along that bug while searching for an entry already reporting my problem,
but that is about remote image references which are sent attached.
Do you think they know a solution to my problem?

In Thunderbird I only installed one extension:
http://minimizetotray.mozdev.org/installation.html
0.0.1.20041101+

Should I attach my prefs.js?

Comment 5

[Rene L.]

Update: This error does NOT occur for writing a new message!
Only if I respond to a message or forward it.

Comment 6

[Rene L.]

Now I got it, the error only occurs here when I respond to messages.
If I write a new message or forward a message, the signature is inserted correctly.

Can you confirm that?

Comment 7

[Mike Cowperthwaite]

(In reply to comment #6)
> Now I got it, the error only occurs here when I respond to messages.
> If I write a new message or forward a message, the signature is inserted
> correctly.
> 
> Can you confirm that?

To be clear:
1) you have a sig that refers to a local image (file://....)
2) you reply AS HTML to a message (itself HTML or plain, or does it make a 
difference?) and the image is visible in the reply
3) you send out the message and it is transmitted as HTML (not converted to 
plain)

But: the image in the sig is not seen; the <img> tag exists in the message as 
transmitted/received, but has a moz-do-not-send=true attribute, an href 
containing a cid: URL, and no attached parts containing the image.

All true?  I still cannot reproduce this symptom.

Comment 8

[Rene L.]

(In reply to comment #7)
> To be clear:
> 1) you have a sig that refers to a local image (file://....)
> 2) you reply AS HTML to a message (itself HTML or plain, or does it make a 
> difference?) and the image is visible in the reply
> 3) you send out the message and it is transmitted as HTML (not converted to 
> plain)
> 
> But: the image in the sig is not seen; the <img> tag exists in the message as 
> transmitted/received, but has a moz-do-not-send=true attribute, an href 
> containing a cid: URL, and no attached parts containing the image.
> 
> All true?  I still cannot reproduce this symptom.


1) yes, two local and one remote images
2) yes, I reply as HTML, all 3 images are visible in the reply, regardless of
replying to a HTML or plain message
3) I choosed the option to send all messages as HTML and plain alternative.

But the problem occurs long before that, immediately after creating a new reply:
the HTML code of all 3 referenced image files in the signature is changed with
moz-do-not-send="true".
Regardless whether there already is a moz-do-not-send="false" attribute in the
signature code or not.

Almost, the code of all three <img> tags in the signature is changed during
creation of the reply with additional linebreaks and the moz-do-not-send="true"
attribute, the rest is left unchanged (meaning full file:// and http:// src
attributes):

<img src="file:///C:/firefox-logo.gif" title="Mozilla Firefox" alt="Mozilla
Firefox" border="0" height="132" width="137">

becomes

<img
 moz-do-not-send="true"
 src="file:///C:/firefox-logo.gif"
 title="Mozilla Firefox" alt="Mozilla Firefox" border="0" height="132"
 width="137">

Yes, no parts are attached containing one or more of these three images.

I attached my nearly unchanged prefs.js, maybe the problem is caused by a
preference.

Comment 9

[Rene L.]

Attachment: Nearly unchanged prefs.js

My nearly unchanged prefs.js, maybe the problem is caused by a preference.

Comment 10

[Rene L.]

I updated Thunderbird to the current release candidate version 1.0RC1 (20041201).
The problem still exists.
I used the german installer, could the problem be related to the localization?
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/1.0rc/contrib-localized/thunderbird-1.0rc.de-DE.win32.installer.exe

Comment 11

[Rene L.]

I updated Thunderbird to the current release candidate version 1.0 (20041206).
The problem still exists.
I used the german installer:
http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.0/win32/de-DE/Firefox%20Setup%201.0.exe

Comment 12

[Mike Cowperthwaite]

If you think the problem is related to prefs, try creating a new profile and see 
if you can reproduce the problem with that.

Comment 13

[Rene L.]

The link to the german installer in Comment #11 was wrong:
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/1.0/win32/de-DE/Thunderbird%20Setup%201.0.exe

Thank you for your hint, now I got the malicious preference:

If you set
  user_pref("mail.identity.id1.reply_on_top", 1);
  user_pref("mail.identity.id1.sig_bottom", false);
the problem occurs.

If you set the default value
  user_pref("mail.identity.id1.reply_on_top", 0);
OR
  user_pref("mail.identity.id1.sig_bottom", true);
all referenced <img> files get attached normally.

Maybe the problem is related to multiple identities.

There is another problem:
if I set the sig_bottom=true value by using the multiple identities dialog, I
can't set sig_bottom=false afterwards.
In the next invocation of the dialog the sig_bottom value is true again!

As you can see in my prefs.js all other identities don't use a signature
(attach_signature=false) and sig_bottom is true (default value).

Comment 14

[Mike Cowperthwaite]

OK, on testing, I see this.  It only suppresses the sig's image in the case of a 
reply, not for a new (Write) message.

Reproduced with TB 1.0, Win2K

Comment 15

[Mike Cowperthwaite]

Also reproduced with Mozilla 1.8a6-1217.  Moving to Core.

Comment 16

[Rene L.]

There is another signature problem if you start a new reply and change to
another identity:

If all identities have
  user_pref("mail.identity.id1.reply_on_top", 1);
  user_pref("mail.identity.id1.sig_bottom", true);
text signatures are replaced upon identity changing during reply.

But if all identities have
  user_pref("mail.identity.id1.reply_on_top", 1);
  user_pref("mail.identity.id1.sig_bottom", false);
and you start a new reply with the first identity and change to another
identity, the different signatures are added on top every time you change to
another identity.

Comment 17

[Mike Cowperthwaite]

One issue per bug, please.  In fact, that symptom has already been reported, I 
believe it's bug 218346; please take more time to search for problems before 
reporting or commenting on them.

Comment 18

[Naikel Aparicio]

This bug is easier to reproduce than stated here in the comments.

Just create an HTML signature with an image on it.  Select in the Composition &
Addressing options in your account "Compose messages in HTML format",
"Automatically quote the original message when replying" Then, "start my reply
above the quote" and place my signature "below my reply (above the quote)". 

Or just:

user_pref("mail.identity.id1.reply_on_top", 1);
user_pref("mail.identity.id1.sig_bottom", false);

And then reply to an email and send.  The email will be sent without images but
a moz-do-not-send="false" option in the img tag instead.

If the signature is "below the quote (recommended)" works fine.

Comment 19

[Mike Cowperthwaite]

*** Bug 287014 has been marked as a duplicate of this bug. ***

Comment 20

[Rene L.]

I just wanted to let you know that the bug still exists for me in Thunderbird
version 1.0.6 (20050716).

Comment 21

[Mike Cowperthwaite]

*** Bug 304820 has been marked as a duplicate of this bug. ***

Comment 22

[Mike Cowperthwaite]

The duplicate states that this same problem occurs if the sig file *is* an 
image, rather than contains one.


(In reply to comment #20)
> I just wanted to let you know that the bug still exists for me in Thunderbird
> version 1.0.6 (20050716).

Until such point as you see a patch posted to this bug, it's unlikely to be 
fixed in any version.  Reminders about the unfixedness of bugs don't get the 
bugs fixed any faster.

Comment 23

[Mike Cowperthwaite]

Testing with TB 1.6a1-0830 (trunk), this bug appears to have been fixed, I 
assume as a result of the fix for bug 305557.  That fix should also appear in 
the current pre-1.5 ("1.8 branch") builds.

Rene L, please check against a current nightly build (or wait for 1.5 to be 
released) and state whether you see this fixed also.

Comment 24

[Ken Gnazdowsky, B.Sc.]

Hi all,

This bug is not fixed ( missing/dropped image signature file on replies ) as
part of TB 1.5 beta 1.

Is there a chance that it will be included in the next production release ( 1.5
??? ) as indicated in the most recent tester notes from [e-mail] ?

Thx again,
Ken

Comment 25

[Mike Cowperthwaite]

Ken is right; in fact, on retesting, I'm seeing the bug still present in the 
trunk as well.  I don't know now what I did when I tested prior to comment 23, 
but I must have done something wrong.  Sorry for the noise.

Comment 26

[Maxim Konev]

Attachment: fixes for the bug

fixes for the bug (mailnews directory)

Comment 27

[Mike Cowperthwaite]

Comment on attachment 198934 [details] [diff] [review]
fixes for the bug

Max, when you request approval on a patch, you've got ask someone specifically.
 I've put David Bienvenu in the requestee field for this one.

Comment 28

[Maxim Konev]

>Max, when you request approval on a patch, you've got ask someone specifically.
> I've put David Bienvenu in the requestee field for this one.

Sorry, was not sure whom should I ask ;)

Comment 29

[Mike Cowperthwaite]

*** Bug 322638 has been marked as a duplicate of this bug. ***

Comment 30

[Mike Cowperthwaite]

This patch has had r+sr since October... could we get it checked in?

Comment 31

[David :Bienvenu]

yes, I'll check it in.

Comment 32

[Mike Cowperthwaite]

*** Bug 339709 has been marked as a duplicate of this bug. ***

Comment 33

[Mike Cowperthwaite]

*** Bug 339773 has been marked as a duplicate of this bug. ***

Comment 34

[Naikel Aparicio]

This bug has been opened since 2004-11-17 05:04 PDT and still no solution.

Isn't that sad, guys?

Comment 35

[Jason Smestad]

I applied the patch to my copy of Thunderbird and it seems to solve the problem. I've been using the patched Thunderbird since 6/1/2006 and I havn't noticed any adverse effects. Please incorporate the patch in the next release!

Comment 36

[David :Bienvenu]

fixed on trunk - I'll put this into 2.0 as well so it'll be in 2.0 Alpha, coming out soon.

Comment 37

[David :Bienvenu]

*** Bug 345489 has been marked as a duplicate of this bug. ***

Comment 38

[[e-mail]]

Comment on attachment 198934 [details] [diff] [review]
fixes for the bug

>+	}
Nit: TAB character crept in here (it's not the first in that file...)

Comment 39

[Mike Cowperthwaite]

V with TB 3a1-0804, Win2K.

Comment 40

[Rene L.]

I tested again, the bug still occurs with Thunderbird 1.5.0.5 (20060719), but not in Thunderbird Portable 2 alpha 1 (20060724).

Thank you all for bringing this annoying bug down after two years, now I can finally answer my mails with my Mozilla promotion pictures again ;)

Now there is just the GUI bug left under Manage Identities -> Edit -> Composition & Addressing.
If I choose "start my reply above the quote" and place my signature "below my reply (above the quote)", the sig_bottom value is still saved as true (it should be false).

Only manually editing the prefs.js after Thunderbird exit makes this option permanent.


Keep up the good work,
René

Comment 41

[Mike Cowperthwaite]

(In reply to comment #40)
> Now there is just the GUI bug left under Manage Identities -> Edit ->
> Composition & Addressing.
> If I choose "start my reply above the quote" and place my signature "below my
> reply (above the quote)", the sig_bottom value is still saved as true (it
> should be false).
> 
> Only manually editing the prefs.js after Thunderbird exit makes this option
> permanent.

Bug 284058 or bug 278453.

Comment 42

[Mike Cowperthwaite]

*** Bug 354606 has been marked as a duplicate of this bug. ***