269225 - replies include view attachments inline

Status: RESOLVED WORKSFORME

(MailNews Core :: Composition, enhancement)

Description

[Glenn Linderman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 MultiZilla/1.6.4.0b
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 MultiZilla/1.6.4.0b

When replying to a message, when there attachments that are viewed inline, and
"automatically quote the original message" is also in effect, the attachments
are then included in the body of the quoted text.

A strong argument can be made that the original message should not include the
"inline viewed attachments"... especially since other attachments, which are not
viewed inline, are not included.  

It can be particularly annoying when someone sends a large text attachment, or a
large picture attachment.... in two ways....

1) In doing replies to such messages, one has to then delete all the
text/picture of the attachment... if they are big, it can take a while to create
the reply composition window... and for text, it can take a while to select all
the text to delete it.  The workaround for this annoyance is to remember to turn
off view attachments inline before choosing Reply, or Reply All, but since the
attachments are often off-screen, there is often no reminder that that might be
necessary, until too late.

2) When other people reply to onesself, after onesself sent a message with a
large text or picture attachment, and here comes back the text or picture, with
no way to delete the attachment... and anyway, it is now part of the message,
rather than being an attachment, so even fixing Bug 2920 wouldn't really help here.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.



Expected Results:  
It would be nice for Reply (and Forward) to have a number of options, that are
currently missing from one or the other or both.

1) Include attachments (regardless of how viewed, include them as attachments,
not as part of the body of the email)
2) Include attachments viewed inline, as inline (does not apply to Forward As
Attachment)
3) Do not include attachments
4) compose in plain-text
5) compose in HTML
6) [Only for forwarding] forward as inlinne
7) [Only for forwarding] forward as attachment

I'm not sure what the best UI is for these.  It is probably easier internally
for these selections to be made before creating the composition window.  

We already have up to 3 icons on the toolbar, Reply, Reply-All, and Forward, and
adding all of the above options would make for a confusing, combinatorial
explosion of buttons, so that is NOT an appropriate interface.  Although I've
often wished for both a Forward as Inline, and a Forward as Attachment icon
instead of a "Forward according to configuration" button.

Allowing these options to be configured globally, or per account, doesn't seem
to offer the ease of selection that I would like.  Some of the options are
already configured globally or per account, and I stumble over that. 
Configuring default behavior is fine, but per message control is often desired.

The default default for these options should be, in my opinion:

A) Do not include any attachments when replying; include all attachments, as
attachments, when forwarding (either as inline, or as attachment).
B) Infer plain-text or HTML composition from the format of the message being
replied to, or forwarded.  An alternate default I'd be equally happy with is to
ignore the type of the message, and use the configured setting for the account
for new compositions.
C) Forward should default to as attachment.

Perhaps the right interface is to have 4 tool-bar buttons:  Reply, Reply with
options, Forward, Forward with options.  To achieve that, "reply-all" would have
to be folded in to the option selection.  Reply with options and forward with
options would pop-up a dialog from which all the appropriate options could be
selected for this message composition.  In the dialog box, the configured
defaults would be automatically selected, so only the ones that should be
changed need to be clicked.

Reply options would include:
Reply to: All vs sender (a pair of radio buttons)  [N.B. sender is overridden by
the Reply-To header if it exists, of course]
Attachment types: (a group of 3 radio buttons)
Composition type: plain text vs HTML (a pair of radio buttons)

Forward options would be:
How to include message body: inline or attachment (a pair of radio buttons)
Attachment types: (a group of 3 radio buttons)
Composition type: plain text vs HTML (a pair of radio buttons)

The general structure of the options dialog could be the same for both reply and
forward, since only the first pair of radio buttons would be different.

For forward, if Forward message body as attachment is chosen, the only valid
option for forwarding attachments would also be as attachments, so that radio
button could be greyed out with the appropriate selection shown, in that case.


Alternately, and much more simply, a solution that would be satisfactory to me
would be to simply never include attachments in the body of replies.  If such
should be appropriately included in some circumstances, it could be done with
"copy"-and-"paste as quotation".

Comment 1

[Mike Cowperthwaite]

Per bug 161775, the attachments shouldn't be included in the reply at all.
It's not clear to me that a "Reply with attachments" (either inlined or 
attached) makes much sense -- the person to whom you're replying already has the 
attachments, doesn't need them back.

I suggest either marking this bug as a dupe of that one, or as WontFix.

Comment 2

[Glenn Linderman]

There is some use for replying, and including attachments... yes the original
sender already has them, but the reply may add additional recipients that don't
have them.  The cost of sending it back to the original recipient may be one
that is appropriate in certain occasions.  But I agree the default action for
replying should be to omit attachments.

Secondly, this bug isn't a dupe of bug 161775, because it discusses the
possibility of adding quite a few more options to the UI, to give per-message
control to the user.

In rereading my bug report, I realized that "button proliferation" was one of
the issues I was grappling with.  Perhaps instead of replacing the current 3
buttons (reply, reply-all, forward) with 4 (reply, reply with options, forward,
forward with options) it could be changed to 2 buttons (reply, forward), of the
sort used for GetMsg... with a little arrow at the edge for the extra options.

Comment 3

[Gervase Markham [:gerv]]

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/

Comment 4

[Glenn Linderman]

Indeed, the problem of replies still inlining attachments that are displayed as
inline still exists, and this possible solution to that and a comprehensive set
of related issues is still not implemented.

While other possible solutions may exist, none seem to have been implemented as yet.

Comment 5

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 6

[rsx11m]

This bug combines a couple of different options, partially covered by other bugs. While bug 161775 excluded all attachments from being included in replies, even if shown inline, bug 384599 in turn introduced a global pref to allow that selection. Secondly, some shortcuts are available for plain-text/HTML switches from the default. The addition of drop-down menus to the Reply and Forward buttons is discussed in bug 17796. Nevertheless, it appears that the sum of those solutions is less than what you are asking for, but that should narrow down the scope of this enhancement request.

> 1) Include attachments (regardless of how viewed, as attachments <snip>)

Standard for forwarding inline, but not for replies.

> 2) Include attachments viewed inline, as inline (<snip>)
> 3) Do not include attachments

This selection has been introduced by the patch for bug 384599, on a global basis for replies, and can be toggled again with Display Attachments Inline
as a per-message option. Not available for forwarding inline at this time.

> 4) compose in plain-text
> 5) compose in HTML

Already possible with Shift+Write and Shift+Reply (but not for Forward,
that's bug 254931) on a per-message basis.

> 6) [Only for forwarding] forward as inline
> 7) [Only for forwarding] forward as attachment

That has been introduced by bug 17796 as a drop-down menu for SeaMonkey, https://nic-nac-project.org/~kaosmos/index-en.html#frwas provides this functionality as add-on for Thunderbird.

Also, how about images embedded in an HTML message as part of the message, rather than being attached? If you want to cover all options, there should be a choice of removing them in an HTML reply/forward as well. Overall, this list looks like quite some efforts would be necessary to add those extensions to the current user interface and backend components.

Comment 7

[rsx11m]

No response from reporter in two months after the last comment was added.
I'm wondering how to proceed with this bug. It is a collection of various
enhancement requests which should probably be better split up into their
own bugs. Some of those are already dealt with or duplicating pending bugs.

This bug should probably be closed (with which resolution then?) due to the
lack of focus, and if there is still some desire to get specific items done,
those opened as new individual bugs.

Comment 8

[Glenn Linderman]

Sorry, I was traveling when that last comment was added, and then it must have gotten lost in the noise later.

bug 161775 sounds like it will fix the major problem/annoyance, but not provide all the options discussed here.  I can't tell what releases include it, maybe none yet?  I look forward to a release containing it.

Regarding embedded HTML images, it seems there has been a bug for some time that they don't get included when forwarding or replying, or if included, that they aren't linked right somehow, because they don't display properly when received.  I don't know if that has an individual bug number or not.  An option to include or exclude them would seem to fit well with the options I listed above.

Regarding handling this bug: I don't know the best process for handling things like this.  Seems like a collection of related stuff could be worked on together, and a unified interface designed.  Splitting everything into their own bug, might result in no unified design, and only partial, or assymetric implementation like now exists for Shift+Write and Shift+Reply (but not Shift+Forward).  On the other hand, a large collection of stuff may never get implemented, if it looks like too big a project.

The way I see it, these are all related topics, and should be designed to provide a uniform user interface.  But if it will never get done that way, it is better to divide and conquer, I guess.

Comment 9

[rsx11m]

(In reply to comment #8)
> Sorry, I was traveling when that last comment was added, and then it must have
> gotten lost in the noise later.

No problem.

> bug 161775 sounds like it will fix the major problem/annoyance, but not provide
> all the options discussed here.  I can't tell what releases include it

The patches for bug 161775 and bug 384599 are in the current nightly builds
for SeaMonkey 2.0a1pre and Thunderbird/Shredder 3.0b1pre (also in the upcoming 3.0 Alpha 2 release). By default, image and text attachments will no longer be included in quotes, but can be enabled by setting the mail.reply_quote_inline preference. The fix doesn't provide any per-case option, this is correct.

> Regarding embedded HTML images, it seems there has been a bug for some time
> that they don't get included when forwarding or replying, or if included, that
> they aren't linked right somehow, because they don't display properly when
> received.  I don't know if that has an individual bug number or not.

There are a couple of bugs related to images included as part of an HTML message, which is independent though from the question of whether or not to
make their inclusion an option.

> An option to include or exclude them would seem to fit well with the options
> I listed above.

I agree.

> Regarding handling this bug: I don't know the best process for handling things
> like this.  Seems like a collection of related stuff could be worked on
> together, and a unified interface designed.  Splitting everything into their
> own bug, might result in no unified design

That's a common problem with more complex redesigns, where it is necessary to keep track of the overall picture, but the individual solutions may better be handled in their own specific spin-off bug.

I'm adding Wayne to the CC list for some suggestion how best to continue.

Comment 10

[Wayne Mery (:wsmwk)]

sorry comment 9 got lost bugmail heaven.

3 suggestions:
1. Glenn try the early release [1] to see how it now behaves
2. discuss in newsgroup
3. retask this bug or file a new one based on ng discussion - if there is a single goal but multiple discrete tasks which can happen independently, file multiple bugs and make the goal a meta bug

[1] early release is quite stable - just protect yourself with backups and test profile  http://www.mozillamessaging.com/en-US/thunderbird/early_releases/

Comment 11

[Glenn Linderman]

Yep, a quick test of Shredder alpha 2 indicates that it doesn't, by default, with my inherited test profile (meaning I didn't have to do anything to make it happen), doesn't include attachments in replies.  I haven't analyzed the performance using messages with huge attachments.

I'm happy.  Whether anyone wants any of the other options in this bug, can be discussed.  As long as the default stays that attachments are not included in replies, I'll be quite happy.  If that were not to be the default, then I would definitely want extra options on reply/forward to eliminate them for my use.

The other items don't bother me a lot, but would occasionally be convenient.  I was trying to list a comprehensive set of functionality, hoping for a unified design, but if that isn't the way things get done, so be it.

Comment 12

[rsx11m]

Resolving this WFM based on comment #11, as it appears that Glenn's primary concern was addressed by other bugs. For any remaining items on the list, discussing solutions first (either newsgroups or a page on wiki.mozilla.org)
and then submitting more focused bugs as enhancement requests on individual issues is probably the way to go.