we aren't getting the "ask format / html question" dialog when sending html mail to two recipients, one prefers plain, one prefers html

RESOLVED FIXED

Status

MailNews Core
Composition
RESOLVED FIXED
14 years ago
9 years ago

People

(Reporter: Scott MacGregor, Assigned: Scott MacGregor)

Tracking

(Depends on: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-aviary1.0)

Attachments

(1 attachment)

(Assignee)

Description

14 years ago
we aren't getting the "ask format / html question" dialog when sending html mail
to two recipients, one prefers plain, one prefers html

While testing (both my tree and the shipping tbird 0.6) I noticed that if I send
an email to "a" and "b", and one prefers html and the other prefers plain text,
we'll down grade to plain text.  We don't even ask the user!  I think this is
strange because the wording of the "ask user" dialog makes me think we should be
asking.

Take a look at
http://lxr.mozilla.org/mozilla/source/mailnews/compose/src/nsMsgCompose.cpp#4116

if any recipient has unknown, we ask the user for a format (ok).
if there is a mix between html and plain, we silently downgrade to plain. (yikes!)
if all recipients want plain, we use plain. (ok)
if all recipients want html, we use html. (ok)
(Assignee)

Updated

14 years ago
Depends on: 44494

Comment 1

14 years ago
seems like we should ask...except, I guess we're just grossly favoring the
prefers plain text user.  And I will say that because of my one luddite friend
who prefers plain text, if I try send html mail to him and a bunch of normal
folks, and this dialog were to pop up, I'd pick plain text.
(Assignee)

Comment 2

14 years ago
thanks for the response, david.

I agree we should ask in that scenario, because we are going to convert the
outgoing message from html to text, and the user should know that before it
happens (instead of it just silently happening).

patch in hand, testing now...
Status: NEW → ASSIGNED
(Assignee)

Comment 3

14 years ago
Created attachment 148081 [details] [diff] [review]
patch
(Assignee)

Comment 4

14 years ago
fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 5

14 years ago
I understand your reasoning, but: Is there anything reasonable the user can
choose other than plaintext or maybe both? Assuming the pref in the card was set
correctly, the plaintext user *cannot* receive HTML (or will be upset if he
does), but everyone can recieve plaintext. I fear that the user might not be
aware (anymore) that one recipient can't recieve HTML and picks HTML for fear of
losing the formatting.

Should we assume that all MUAs properly support multipart/alternative by now and
just silently send "both" in this case?

Comment 6

14 years ago
One thing that might help address Ben's issue is change the text of the setting 
in the address-book from "Prefers plain text" to "Requires plain text."

This is the same issue as bug 187064, which Ben wontfix'd just a couple weeks 
ago.
OS: Windows 2000 → All
Hardware: PC → All

Comment 7

14 years ago
I can verify that this change is working as described in
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040510

Another thing that could be done about Ben's concerns: for this particular "one 
recipient Prefers Plain" case, disable the "HTML only" radio.

Also, if the "remember my decision for Unknown recipient[s]" checkbox (per 
discussion in bug 44494) is implemented: in this case, that checkbox should be 
unchecked by default.  I've considered whether it should be disabled as well, 
but I don't think that's necessary.

In fact, I'd say that in the "one-Prefers-Plain" case, any Unknowns should not 
be updated, at least until such point as the checkbox is in place.  It's not 
reasonable to mark the Unknown(s) as Prefers Plain if Send As Plain is chosen 
for the sake of the Prefers-Plain recipient; and if Send As Both is selected, 
the decision of how sensibly to mark the Unknown(s) is far too complex to 
describe to the user.  (This is related to the issue raised by Ben in 44494 
about multiple Unknowns on the recipient list.)  I can open another bug for this 
point if people agree that it's an issue.

(Maybe Scott is already suppressing updates of the AB in this case; I can't 
check because updating the AB -- the patch from 44494 -- doesn't appear to be 
working in my build.)
(Assignee)

Updated

14 years ago
Whiteboard: fixed-aviary1.0
Blocks: 245520
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.