Closed Bug 56834 Opened 24 years ago Closed 8 years ago

Add Preference for new addressbook card's default 'send format' (html or plaintext)

Categories

(MailNews Core :: Address Book, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: Brade, Unassigned)

References

(Blocks 3 open bugs)

Details

I would like a pref to control how entries are defaulted in the addressbook.
Right now, the "Collected Addresses" portion of the AddressBook is collecting
many e-mail addresses but they are all defaulting to 'plain text' rather than
'html.'  I'd like to be prompted or be able to set the default setting for each
address added.
RFE.  Reassign to Candice.  Not RTM.
Assignee: selmer → chuang
Severity: normal → enhancement
Target Milestone: --- → Future
QA-assign-to fenella.
QA Contact: pmock → fenella
QA Contact: fenella → nbaca
reassigning to racham.
Assignee: chuang → racham
mass re-assign.
Assignee: racham → sspitzer
*** Bug 76241 has been marked as a duplicate of this bug. ***
Old summary: would like pref to control how entries are defaulted in AB.

Autocollected addresses always default to 'Unknown' on my build, but the
enhancement request still applies.
Summary: would like pref to control how entries are defaulted in AB → Preference for new addressbook card default 'send format' (html or plaintext)
I would like to add upon this.

when I use collected emails that have unknown prefs, pop up comes.
Id like that popup to allow me to select prefs for each recipient,
and commit them.  A 2 column table: email => format-pref radio-buttons.
an additional text box => radio-button pair would allow setting a pref,
ex HTML, for "att.net, aol.com, msn.net", etc..

Another option is to have the MailNews program auto-learn the format. For
example, I just sent three messages in a row to a user and each time I specified
HTML. Thundirbird could have deduced that HTML is the preferred format for that
user. Of course, a check button that says "Make this format the default for the
user" is also a good step in this direction.

L
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Assignee: mail → nobody
Component: Address Book → MailNews: Address Book
Product: Mozilla Application Suite → Core
QA Contact: nbaca → addressbook
Target Milestone: Future → ---
does this not block bug 44494, as without a pref to set (this bug) there can be no prompt?  (or maybe i'm not reading this correctly)
Blocks: 44494
Product: Core → MailNews Core
Priority: P3 → --
Everywhere I go, Wayne has been there first ;)

CC WADA, rsx11m re Delivery Format | Auto-Detect...
Summary: Preference for new addressbook card default 'send format' (html or plaintext) → Add Preference for new addressbook card's default 'send format' (html or plaintext)
(In reply to Kathleen Brade from comment #0)
> but they are all defaulting to 'plain text' rather than 'html.' 

It's inaccurate, at least after sorting out of code by bug 970118 in 2014.
1. When Prefers=Unknown is detected, it's considered as "mix of HTML Domain recipients + Text Domain recipients".
   (allHtml=false, allPlain=false is set)
2. Upon send HTML mail, following is currently executed by Auto-Detect.
   if(allHtml) Do action for allHtml; else if (allPlain) Do action for allPlain; 
   else if( (!allHtml && !allPlain) && Convertible-To-Text ) send text/plain; // for Text Domain recipient
   else if( (!allHtml && !allPlain) && Not-Convertible-To-Text ) use Send Options setting;

Although Prefers=HTML/Text/Unknown is used in Auto-Detect, "default of Prefers in Address Book" should be defined/set as "entity of Address Book".
There is no need to actually change Prefers=Unknown in Address Book to Prefers=HTML/Text.
Following is sufficient.
  In Auto-Detect, interpret Prefers=Unknown as HTML or Text based on "default of Prefers in Address Book".
Please see pseudo code attached to bug 1218156. Top half is for this.
Because "default of Prefers in Address Book" is referred by Auto-Detect and used by "Send Options", UI for setting/changig "default of Prefers in Address Book" is better placed in "Send Options" panel.
> Bug Summry : default 'send format' (html or plaintext) 

Is Prefers=HTML/Text/Unknown is actually 'send format'?
Is there any plan of Prefers=Both or Prefers=Ask which exists in Send Options panel?
Prefers=HTML or Prefers=Text is "per email address HTML Domain setting/Text Donain setting", isn't it?
If "Prefers=HTML/Text/Unknown in Address Book" is "prefers send format", who prefers? HTML mail creator(Tb user)? or the Contact in Address Book(=mail recipient)?
FYI. "send format" in bug summary was introduced by Joe Infla on 2003-12-16. Bug opener didn't say such thing.
If new entries in AB default to "Unknown", then implementing bug 1222176 will create the pref to say what the "Unknown" value means. So implementing that one makes this bug probably unneded.
Depends on: 1222176
This old bug was trying to address a real problem (which was much more problematic when we still nagged users every time about the send format), but in the wrong way.

This bug wants that every new contact defaults to a certain format preference between plaintext or HTML (per-contact prefers-both unfortunately hasn't been implemented, although it's actually simple, as seen in my patch attachment 8693334 [details] [diff] [review] of bug 1222176). Per this bug, the default value for everyone would then be hardwired for each recipient. A per-recipient hard-coded setting doesn't make sense if it's just the default value, especially when the user might change his mind about the best default value at a later point, which would then require resetting each and every contact.

I agree with WADA's comment 14 that it would sufficient, much better and more future-proof to map prefers-unknown (i.e. use default format) into a centrally defined default format for recipient-centric auto-detect (prefers-something, if you so wish: prefers-plaintext|html|both), as seen in my patch attachment 8693334 [details] [diff] [review].

So regardless if recipient-centric auto-detect has a future or not (see bug 1222176 comment 85 which suggests to remove that feature), the solution here would be unwanted -> Wontfix.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.