Closed Bug 921836 Opened 9 years ago Closed 8 years ago

Although recipient "prefers HTML", message is sent in plaintext because of "Format Auto-Detect"

Categories

(Thunderbird :: Message Compose Window, defect)

24 Branch
x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: hendrik.haddorp, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130911160237

Steps to reproduce:

1) Preferences -> Composition -> Send Options
    Text Format = Send the message in both plain text and HTML
2) write a new mail
3) add a recipient from your address book that has "Prefers to receive messages as formatted as" set to "HTML".
4) leave Options -> Delivery Format to its default "Auto-Detect"
5) write a simple mail without any formating
6) send the mail


Actual results:

the mail is sent in text/plain


Expected results:

The mail should be send in HTML, or text/plain and HTML. Given that the recipient has a prefered format set to HTML it should actually be ok to just send in it in that format.
Summary: mail is send in text/plain even when recipient prefers html → Message is sent in text/plain even when recipient prefers html (delivery format auto-detect)
> 3) add a recipient from your address book that has "Prefers to receive messages as formatted as" set to "HTML".

I agree that when all (!) recipients are recorded to "Prefer HTML", we should send as HTML or plaintext + HTML.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Message is sent in text/plain even when recipient prefers html (delivery format auto-detect) → Although recipient "prefers HTML", message is sent in plaintext because of "Format Auto-Detect"
What if you have multiple recipients and only one is known to prefer HTML? Shouldn't the mail get send in HTML and plain text then if TB is configured to normally send both?
This:
> 1) Preferences -> Composition -> Send Options
>    Text Format = Send the message in both plain text and HTML

is a different issue. I think it's already filed as bug.
Hendrik, I write "Always HTML" extension, that fix "Format Auto-Detect" to always send HTML if You editing in HTML mode.
(In reply to Ben Bucksch (:BenB) from comment #3)
> is a different issue. I think it's already filed as bug.

This bug occurs even when non "simple HTML mail which Tb's auto-detect wants to send in text/plain".
(1) Composition option/Send Option/Text Format = Always me what to do
    HTML mail with comlex layout(bold, italick, color, font,  ...)
    To: mail address = Registered to Address Boook, preferenece=HTML
    (not "not registered to AddrBook", not "pref=Unknown", not "pref=Text")
(2) Send Later
    => Even though all recipients are "registered to Address Book, pref=HTML",
       frmat is asked.

This indicates;
- "preference=HTML in Address Book" is not effective
- if Send Option/Text Format = text/plain, sent in text/plain despite of "pref=HTML".
- if Send Option/Text Format = text/html, sent in text/html despite of "pref=Text"
  as designed.

I suspected bug 889152, but someone says "problem of this bug is not resolved by Tb 27 Beta on which fix of bug 889152 should be landed" in a forum

Ben Bucksch (:BenB), which bug is the "already filed bug"?
Bug 874020?
Keywords: regression
Sorry, typo.
  Send Option/Text Format = Always ask me what to do
Doing some code archaeology for other reasons, I suspect this is a regression from bug 872041, which is itself a regression fix for bug 68784. This suspicion was caused by merely reading the changes, which made me go "WTF does the patch author think he's doing?"
Blocks: 872041
FWIW, if no one else gets to this first, I'll probably fix this bug in bug 970118
To Ben Bucksch (:BenB). Is Bug 401014 relevant to this bug?
no
the problem seems to be resolved on TB31. so changing the bug to resolved.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Depends on: 970118
You need to log in before you can comment on or make changes to this bug.