Closed Bug 239698 Opened 20 years ago Closed 19 years ago

Unable to edit HTML attachments when forwarding but can when replying

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: carl_601, Assigned: mscott)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040322 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040322 Firefox/0.8.0+

When receiving a message with an HTML attachment if I reply the text content of
the HTML attachment are shown in the compose window and I am able to edit it,
however if I forward the HTML attachment shows in the Attachments window but the
text does not show in the compose window therefore is un-editable

Options are set to Tools>Options>Composition>Forward Messages>Forward messages:
inline

Reproducible: Always
Steps to Reproduce:
1.Write a message,
2.Create an HTML file and attach it to the message, I used the following:

<HTML>
<BODY>
<P>This text can be edited when replied but not when 
forwarded</P>
</BODY>
</HTML>

3.Send the message to yourself,
4.Reply to the received message and the text in the HTML file will show in the
compose window and can be edited,
5.Forward the received message and the HTML file shows as an attachment but the
text does not show in the compose window therefore can't be edited.



Expected Results:  
The text content of the HTML attachment should be editable when forwarded as it
is when replied.
Using build Mozilla Thunderbird 0.5+ (20040330)
are you set to fwd attachments as inline or as attachments?
(In reply to comment #2)
> are you set to fwd attachments as inline or as attachments?

I have options set to:

Tools>Options>Composition>Forward Messages>Forward messages: inline

Is this what you mean?
This may be the same bug as reported in...

http://bugzilla.mozilla.org/show_bug.cgi?id=215265
I believe the problem is with the Reply case, not the Forward case.

If you do not display attachments inline, then Reply does not include any of the 
attachments -- the reason being, your correspondent *sent* that data and doesn't 
need to see it again.  If attachments are displayed inline, they are included in 
the quoted text in a reply (when possible, images of course are not included in 
a plain text reply) -- this is bug 161775.

Recommend this bug be resolved Invalid, as the "expected results" should not be 
expected.


Forwarding mail assumes that you want to send a copy of the original mail to 
somebody else.  If you forward inline, the attachments from the original appear 
in your attachment list (and you can delete them if desired); if you forward as 
attachment, the forwarded message is un-editable.

Bug 215265 is a separate problem.
(In reply to comment #5)

The problem is with the *forward* case not reply.

When I read an HTML email the HTML text appears inline, however when I try to
forward these the HTML text appears as an attachment and is not editable within
the compose window.

This behaviour can be replicated by following the 'Steps to Reproduce' I placed
in  the original posting above.

I have tried this with version 0.7.3 (20040803) and the behaviour is still the same.
Yes, the behavior you reported is easily reproducible; but your expectations are 
misguided.  Reply *should not* be quoting attachment text; Forward *should* be 
copying attachments *as* attachments.
(In reply to comment #7)

Maybe I am not describing the problem very well, or maybe it is normal 
behaviour but it is not the behaviour I would expect to see and don't see it 
in my other email client.

I believe the behaviour I am seeing is the same as described in Bug 215265. 
The messages I refer to are usually ones that have been forwarded several 
times and contain several "From:" lists, it is these that I want to edit out. 
When opening a message the 'Froms:' appear inline but when forwarded they 
appear as HTML attachments and are not editable within the composition window. 
I want to be able to edit these emails so that the people I send to don't have 
to scroll down pages of 'Froms:' before they get to the message. I could 
delete the HTML attachments containing the 'Froms' but this means opening each 
one individually to see what the content is.
(In reply to comment #8)
> Maybe I am not describing the problem very well, or maybe it is normal 
> behaviour but it is not the behaviour I would expect to see and don't see it 
> in my other email client.

Your original report in comment 0 seems perfectly clear to me.
Your "clarification" in comment 8 is much harder to understand.


> The messages I refer to are usually ones that have been forwarded several 
> times and contain several "From:" lists, it is these that I want to edit out. 
> When opening a message the 'Froms:' appear inline but when forwarded they 
> appear as HTML attachments and are not editable within the composition window. 
> I want to be able to edit these emails so that the people I send to don't have 
> to scroll down pages of 'Froms:' before they get to the message. I could 
> delete the HTML attachments containing the 'Froms' but this means opening each 
> one individually to see what the content is.

My understanding:  The original person sent out some bit of jollity, as a 
message body or maybe as an attachment originally, I don't know.  Someone up the 
line forwarded that message *as* an attachment.  This would not be "an HTML 
attachment" but "an attached message" and would include mail headers (like 
"From:...).  This may have happened several times, so you finally received a 
message structured like this:

  To: Carl
  From: Bob
  Attached: message3
     To: Bob
     From: Joanne
     Attached: message 2
        To: Joanne
        From: Englebert
        Attached: message 1
           To: Englebert
           From: Pete
           Subject: Aren't I a wit?
           <content here>

In other words, the attachments are nested: the attachment you received contains 
a message which itself has an attachment, and so on down the line.  These 
attachments should all have little envelope icons, because they are messages.  
If the original item was sent as an attachment instead of as a message body, 
then it would have its own icon (i.e. an HTML file icon).

(Bug 35587 is about the problem where a message like the one you get shows, in 
the attachment list, *every* nested attachment as a top level one.)

If I have correctly described the message you have received:  I wouldn't want to 
use a mail client that handles forwarding such a message the way you believe it 
should be handled.  To my mind, that behavior is wrong.

The way I would do this would be to either copy the text of the original message 
and paste it into a new message, or open every one of those attachments until I 
figured out which was the original, and drag that attachment to the attachment 
box of a new message.

If the technique described in bug 35587 comment 10 were actually implemented, it 
would make that a little easier because you could tell which attachment was the 
original.
(In reply to comment #9)

The messages I refer to contain attachments, the example I give below has 2 
attachments (Part 1.2(html) and picture.png). What I am actually seeing is a 
received messages that when opened looks somethings like this in the message 
body:

>To: Bob
>From: Joanne
>Subject: FWD: FW: Aren't I a wit?
>Date: 29 Aug 2004
---------------------(horizontal rule)
>To: Joanne
>From: Englebert
>Subject: FW: Aren't I a wit?
>Date: 29 Aug 2004
---------------------(horizontal rule)
<attached picture>

And when I reply I get this in the composition window:

-------- Original Message --------
<table containing header of message sent to me, i.e. To: Carl, From: Bob etc>

<message body>
>To: Bob
>From: Joanne
>Subject: FWD: FW: Aren't I a wit?
>Date: 29 Aug 2004
<end of message body>

<attachment 1 [details] [diff] [review]>:  (HTML content) >To: Joanne
                                >From: Englebert
                                >Subject: FW: Aren't I a wit?
                                >Date: 29 Aug 2004

<attachment 2 [details] [diff] [review]>:  <picture.png>

What I was expecting is that the body of the message in the <forward> 
composition window to look the same as the message I receive, i.e. in-line 
with the addition of the <table containing header of message sent to me, i.e. 
To: Carl From: Bob etc>. Should <Forward messages :inline> not allow you to 
view and edit them inline too?.

Are the cases in comment 0 and comment 8 not the same? In both cases the text 
content is viewed in-line in the original message body but are viewed as 
attachments in the forward composition window.
(In reply to comment #10)
> Should <Forward messages :inline> not allow you to 
> view and edit them inline too?.

If the part you want to edit was an attachment in the original mail, I would say 
no (as I said in comment 7).


> Are the cases in comment 0 and comment 8 not the same? In both cases the text 
> content is viewed in-line in the original message body but are viewed as 
> attachments in the forward composition window.

In the context of the behavior we're discussing, yes, they work out to the same 
thing.  There is a difference in the details: in comment 0, it seems that the 
HTML attachment itself -- the content that you want to forward -- is the thing 
that you want to edit; in comment 8, it seems that the thing you want to edit is 
all the levels of nested forwarding (the "From..." stuff) which are not, 
themselves, HTML attachments.


Besides the about display of nested attachments (bug 35587 and bug 203570), 
there's also bug 204350, about an attached email opened in its own window. 
Currently, those windows are not fully functional -- you can't reply or forward 
or much of anything with them.  If this was fixed, then that feature would 
bypass your problem: you could open the innermost-nested email, the original 
with the HTML content, and then forward that (or Edit as New), leaving behind 
all the rest of the stuff.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.