306303 - Automatically use / allow HTML formatting when replying to HTML mail

Status: UNCONFIRMED

(Thunderbird :: Message Compose Window, enhancement)

Description

[Pepijn Schmitz]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: 1.0RC1

When the "text format" setting is set to "ask me what to do", and the "compose
messages in HTML format" checkbox is checked, and I reply to an HTML-formatted
email from someone who isn't in my address book, or whom I haven't marked as
being able to receive HTML-formatted email, Thunderbird will (correctly,
according to the settings) ask me in which format to send the email.

It would be very nice if in this situation it would automatically allow the HTML
format, since the fact that I am replying to an HTML-formatted email means that
the sender obviously can handle HTML formatted emails. It could be smart about
it (e.g. only do it when I'm replying only to the sender, and not when I'm
replying to multiple recipients, or something like that).

Also, when replying to an HTML-formatted email it would be nice if Thunderbird
would (perhaps conditionally on a setting) automatically use the HTML format,
even if the default format is not set to HTML.

I guess, in more general terms, it would be good if Thunderbird would take the
properties of the replied-to email into account, since that is the best
indicator it has of which properties the reply should have. Perhaps there are
other aspects to which this principle could be applied.

Reproducible: Always

Steps to Reproduce:
N/A
Actual Results:  
N/A

Expected Results:  
N/A

N/A

Comment 1

[Adam Guthrie]

Is this not possibly with Tools > Account Settings > Composition and Addressing
> "Use HTML by default"?

Comment 2

[Pepijn Schmitz]

> Is this not possibly with Tools > Account Settings > Composition and
Addressing > "Use HTML by default"?

No, because then it would _always_ use HTML, even if the email I'm replying to
is not in HTML format and it cannot therefore be assumed that the sender can
handle HTML.

This is in fact the setting I use, but if the recipient is not listed in my
address book as being able to receive HTML, I still get a question asking in
which format to send the email. I don't want to set it to always send HTML and
text, because I consider that wasteful, and also someone who can't handle HTML
quite possibly also can't handle a multipart email.

Comment 3

[Mike Cowperthwaite]

xref bug 233412 -- dupe?

Holding the Shift button while clicking Reply will start up the composed message 
in the opposite mode from that normally used: if you're set up for plain, 
Shift+Reply starts the reply as HTML, and vice versa.

Comment 4

[Pepijn Schmitz]

(In reply to comment #3)
> xref bug 233412 -- dupe?

Not a dupe, but definitely related. That bug is so old that it doesn't seem to
apply to the way Thunderbird currently works anymore anyway, since Thunderbird
doesn't display the behaviour which is mentioned in the last comment on that bug.

> Holding the Shift button while clicking Reply will start up the composed message 
> in the opposite mode from that normally used: if you're set up for plain, 
> Shift+Reply starts the reply as HTML, and vice versa.

I didn't know that. Thanks for the tip. It doesn't satisfy my request though;
the point of this change would be that it would be fully automatic.

Comment 5

[John Thomson]

This is close to the behavior of other clients which have a setting for "Reply to messages in the format in the format in which they are sent" (OSX Entourage) or "Use the same message format as the original" (OSX Mail).
The idea is to keep the default compose formatting, but to automate the format on replies (with the ability to override w/ shift-click).

Comment 7

[Charles]

Adding my voice in support of a simple 'Reply/Forward in same format as original' option.

I would like this to apply to Forwards as well, since quite often HTML formatted messages have bullets/tables in them that become totally unreadable in plain text format.

Also, re: comment 3, yes, the shift key is a workaround for those who use the toolbar buttons to manage email, but for those of us who use the keyboard, CTRL-SHIFT-R is already used for Reply All, so you cannot use the SHIFT key workaround on the keyboard.

Comment 8

[Charles]

(In reply to comment #7)
> I would like this to apply to Forwards as well, since quite often HTML
> formatted messages have bullets/tables in them that become totally unreadable
> in plain text format.

Although it was implied, I should have specified 'Inline Forwards' above - quite often our users need to be able to edit the contents of the message (removing contact info, etc), but also need to maintain the html formatting.

As I said, we deal with a lot of heavily formatted html messages (lists/tables etc) - we are a sales organization, and asking them not to use html formatted messages is an exercise in futility.

Fixing this this would solve a whole category of support issues I deal with on a daily basis.

Comment 9

[Charles]

(In reply to comment #3)
> Holding the Shift button while clicking Reply will start up the composed
> message in the opposite mode from that normally used: if you're set up for
> plain,  Shift+Reply starts the reply as HTML, and vice versa.

And this doesn't work for Inline Forwards...

No response from a dev in over 4 years?

Is this bug not going to get any love? This simply cannot be that hard to do, since the underlying functionality is already there - and an extension already tries to accomplish the behavior (and it works, sortof, sometimes).

Comment 10

[Charles]

Come on devs... someone at least please confirm this feature request as 'New'...

This is really, imho, a basic and essential behavior bug, not a feature request...

Comment 11

[Thomas D. (:thomas8)]

(In reply to Charles from comment #10)
> Come on devs... someone at least please confirm this feature request as
> 'New'...
> 
> This is really, imho, a basic and essential behavior bug, not a feature
> request...

Pepijn & Charles, your input is appreciated. Unfortunately with thousands of bugs around, and a very small team of TB devs, it's not possible for them to respond everywhere.

As a volunteer contributor, allow me to add these remarks:
From many years experience, this bug is not likely to receive much attention for two reasons:

1) comment 0 does not follow the prescribed format of a bug/rfe report:
* Steps to reproduce = STR (including the details of your settings)
1.
2.
3.
* Actual behaviour
* Expected behaviour
All of these with in note form, short and concise (avoid long sentences).
Bugs that follow that format will have a much better chance of getting attention, because anything else simply is too complex to parse and the format will also force you to be more precise in saying what you actually want. I'm not saying comment 0 cannot be understood; but it's far from offering a concise & detailed concept (including behaviour description, UI proposals, mockup screenshots etc.) of what you envision.
So the first step to move this forward would be to provide this information in the correct format in a subsequent comment (and somebody will then add a note in whiteboard pointing to the new STR).

2) IMO, this is far from being a "basic & essential behaviour bug". I believe TB's default setting for composition is now "HTML" format. Mail readers that cannot handle HTML format are certainly an almost extinct species. And most users either don't care or, as Charles describes for his business scenario, they need HTML anyway. There are loads of bugs/rfe's which are far more painful/pressing than this one.

Comment 12

[Charles]

(In reply to Thomas D. from comment #11)
> Pepijn & Charles, your input is appreciated. Unfortunately with thousands of
> bugs around, and a very small team of TB devs, it's not possible for them to
> respond everywhere.

Understood and agree, however, it really shouldn't take multiple *years* either...

;)

> From many years experience, this bug is not likely to receive much attention
> for two reasons:
> 
> 1) comment 0 does not follow the prescribed format of a bug/rfe report:

Rather than doing the above (which just seems messy to me), how about if I open up a new bug, and we dupe this one to that?

If you are ok with that, I'll be happy to do it...

> 2) IMO, this is far from being a "basic & essential behaviour bug".

No problem with your difference of opinion, but that doesn't change mine... ;)

> I believe TB's default setting for composition is now "HTML" format. Mail
> readers that cannot handle HTML format are certainly an almost extinct
> species. And most users either don't care or, as Charles describes for his
> business scenario, they need HTML anyway. There are loads of bugs/rfe's
> which are far more painful/pressing than this one.

Can't argue much with this one, other  than to restate what I said previously - the bulk of the work is already done, and I simply can't imagine that it would be that difficult to implement since all of the pieces are there - meaning, TB can already reply in either/or, all that needs to be done is simply detect which format the original is in, and pick that format for the reply.

In my opinion (I have a lot of those ;), bugs that are very easy to implement *and* that everyone agrees would be a good thing, regardless of how important they personally may think it is, should be high on the list of bugs to implement, again, especially if most of the work is already done via an extension.

Anyway, no worries, either way...

Comment 13

[Thomas D. (:thomas8)]

Coming from bug 414299 with more insights into TB's problematic default behaviour for sending HTML messages (or not).

I think TB's default behaviour and UI has substantially changed since when this was reported.

There are a lot of settings (Options | Format, and settings listed in Bug 414299 Comment 68) whose interaction is not fully transparent and predictable, especially when Format:Auto-Detect starts to remove HTML tags deemed irrelevant and then sends HTML composition as plaintext anyway.

This general idea looks like a valid request for enhancement:
- if original msg is HTML, it's safe to assume that sender of that msg can receive HTML.
- if reply-all, there might be some recipients with "prefers: unknown" (for which nowadays it would be safe to send HTML anyway, otherwise respect general setting described in next point)
- if reply-all or adding recipients with AB-card-setting "prefers: plaintext", we should do as defined by user in general setting:
> Tools > Options > Composition > Send Options > Text format > When sending
> messages in HTML format and one or more recipients are not listed as being
> able to receive HTML:
> [Send the message in both Plain text and HTML]
> mail.default_html_action;3

However, I'm not sure how this is compatible with Auto-Detect's good intention of avoiding to send HTML if there is no formatting applied.
So I am still hesitant to confirm this, for 2 reasons:
- This bug is not clear enough about expected behaviour/interaction with existing settings, all scenarios considered
- I personally do not fully understand current interaction/behaviour of existing settings and various scenarios that influence plain text vs. HTML

Comment 14

[Thomas D. (:thomas8)]

This is essentially a duplicate of bug 162554 (but this bug is in better state, so it might be better to dupe bug 162554 to this bug 306303.

I think this idea is outdated and trying to solve problems which we no longer have, in a wrong and unsustainable way.

- "Ask me" is no longer the default, so the main motivation of this bug (to avoid the nagging) is gone.
- We have Auto-Downgrade for sending simple HTML messages as plaintext (when they look like plaintext because there's virtually no HTML formatting).
- For all other types of messages (non-trivial HTML), we just want/need to send HTML from HTML compositions, to preserve the formatting (UX-wysiwyg).
- In 2015, HTML is no longer a problematic send format
- In view of the above, switching every contact explicitly to "prefers-HTML" isn't necessary nor helpful, when all we originally wanted here is to "just let me send HTML without getting asked".
Per-Recipient settings are a very clumsy and hard-to-reverse way of achieving that.

And if we are very honest, since everybody can receive HTML messages (even when some devices might downgrade them for the recipient) nobody cares much about the recipient's actual preferences.
It's much more message-centric these days, so if my message content requires HTML formatting, I'll just send that without thinking about recipients.

Better solutions:
- Message-centric: Let user set per-identity default message delivery format (auto-detect | plain(?) | html | both). Like "Default message delivery format" option seen
at the top of attachment 8673807 [details].
- Recipient-centric: let user explicitly define global default format preference for prefers-unknown: map prefers-unknown to prefers-something (plain | html | both) - bug 1222176.