1215791 - Prefers=Unknown case should be removed from nsMsgCompose::DetermineHTMLAction

Status: VERIFIED INCOMPLETE

(MailNews Core :: Composition, enhancement)

Description

[WADA:World Anti-bad-Duping Agency]

+++ This bug was initially created as a clone of Bug #1210244 +++

Prefers=Unknown case  should be removed from nsMsgCompose::DetermineHTMLAction.

Solution consists of:
(1) Remove Prefers=Unknown
(1-1) New user's prefrence for default of Prefers=Unknown (true=Text, false=HTML)
(1-2) In allHtml/aallPlain determination logic,
      convert Prefers=Unknown to HTML or Text
(2) Improvement in send logic.
   4879 nsMsgCompose::DetermineHTMLAction(int32_t aConvertible, int32_t *result)
 - 4978   if (aConvertible == nsIMsgCompConvertible::Plain || allPlain)
 +        if (aConvertible == nsIMsgCompConvertible::Plain)
Logic is changed to:
  (i)   if(allHtml) send text/html
  // at least one recipient is Text Domain reciipent(allPlain, or "HTML + Text")
  (ii)  else if(Covertible=Yes) send text/plain
  (iii) else if(Convertble=No) use Send Options panel
(3) Wording change in Send Options panel,
    because used by both allPlain case and "HTML+Text" case.
(4) Fix Bug 584313 (CSS Style).
    To reduce (ii) due to Convertible=Yes by CSS atribute, bug dix is needed.

Comment 1

[WADA:World Anti-bad-Duping Agency]

Trick is:
- User usually keeps Prefers=Unknown of almost all Contacts in All Address Books.
- Many recent Tb users expect HTML for Prefers=Unknown.
  (when Text Domain/HTML Domain only era, Unknown should be similar to Text Domain for majority of users)
- So, many users set HTML as default for Prefers=Unknown.
=> Current "Prefers=Unknown recipient only" case is automatically changed to allHtml case.
=> problem automaically disappears in many user's environment.

Comment 2

[Thomas D. (:thomas8)]

FTR, Aceman and I agree that we must also offer flavor of unknown==both (multipart/alternative plaintext+html). Both is legitimate, useful and recommended send format *especially* suitable for recipients whose preference is unknown. Having an explicit text variant is safer than relying on recipient mailer to auto-downconvert from HTML-only. Maybe recipient mailer was coded by person like who coded auto-downconvert in TB, so it might not be predictable and bring many surprises to recipient.
Note that "both" is currently *default* send format for mixed cases.

We can make unknown==html-only the default to avoid both if that helps to avoid both where not needed.

Offering unknown==both is elegant and sufficient workaround for missing preference of prefers-both for each contact. If user chooses unknown==both, auto-detect will simply determine "both" for most (if not all) cases involving unknown (maybe involves-prefers-plain might differ). It's really simple and does not give us any extra headaches.

This must be decided before implementing solution for this bug, because if "both" is included, boolean is not sufficient for this pref.
I think it's also more consistent to use same delivery format constants used for send options or delivery formats currently, instead of boolean.

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #2)
> FTR, Aceman and I agree that we must also offer flavor of unknown==both
> (multipart/alternative plaintext+html).

Thomas D., please add such comment after you did following which I wrote in Bug 1210244 Comment #173.
> Please enhance Send Options and Address Book for "Both" by yourself, which both of you want, before saying complaint to me.
> Please implement Prefers=Both in Address Book and "Both Domain" in Send Options.
Please don't confuse following.
 (a) (a-1) HTML Domain/Text Domain in Send Options panel with (a-2) Prefers=HTML/Text in Address Book
 (b) (b-1) Delivery Format=Both/HTML/Text menu and (b-1) Ask/Both/HTML/Text for action/format in the panel

Comment 4

[WADA:World Anti-bad-Duping Agency]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #2)
> This must be decided before implementing solution for this bug, (snip)

Decided? By whom, what was decided?
I merely asked you to create a mock-up of a possible futute Send Options panel.
I never agreeed on the mock-up in that bug, even though I thought a part of the mock-up is useful in near future.
UI for "new prefs in new solution of this bug" will be required, even if "set via Config Editor" is sufficient initially.
And, part of your wording change in the mock-up is usable in "wording change in panel" of this bug's solution.

Comment 5

[Dan Pernokis]

For the case of all-plain-text recipients, I still have concerns about how HTML is handled (i) during preparation and (ii) storage of the message after sending.  I've mentioned this in other related bugs and seems to get ignored.

(1) What happens if I prepare a fancy-looking (ie- HTML) message but all (perhaps only ONE) current recipients happen to be plain-text, and I save the message in draft to be recalled and sent later?  When re-opened, is the message still formatted, or has it been down-graded to plain?  This matters, because I might want to add more recipients, any of whom could prefer HTML.  (And it could easily happen if my initial list included only one recipient that happened to prefer plain-text, such that "all" one recipients prefer plain.)  Downgrade to plain-text -- if it is going to happen -- must not occur until all user edits are complete and the actual SEND process begins.

(2) After my fancy message has been sent, even if "all" recipients prefer plain, how is the message stored in my SENT folder?  If I went to the trouble of formatting, I'd like that to be retained please, for possible forwarding or re-sending (to HTML clients, for example), and certainly for printing and archiving.  I think users would always want the SENT copy to be as they created it (including any formatting) and not how TB eventually sent it out (perhaps plain-text only).

Personally, I still prefer default preference to be "both", but I can settle for "HTML-only" if it doesn't cause problems downstream.

As for WADA Comment #1:
>> User usually keeps Prefers=Unknown of almost all Contacts in All Address Books.
I expect there are indeed a lot of recipients with "unknown".  People have hundreds (or thousands) of addresses in their Collected Addresses book, many of them treated as permanent because they are there.  Likely most of them were added automatically ("collected"), with default set to "unknown", likewise automatically.  The majority of people don't clean up and purge their address books as they should, probably because they don't know.

Comment 6

[WADA:World Anti-bad-Duping Agency]

To aceman.
Please change pseudo code to correct patch and land it, before this bug will be filled by flood of complaints, as done in Bug 1204379 and Bug 1210244.

Comment 7

[WADA:World Anti-bad-Duping Agency]

To aceman.
I merely presented a possible change which was found in Bug #1210244 which was based on your first one-line patch.
I don't touch this bug any more, as I stopped to touch Bug 1202227 and Bug 1202276 any more.
Please morph this bug freely as you want.

Comment 8

[Thomas D. (:thomas8)]

(In reply to WADA from comment #4)
> (In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment
> #2)
> > This must be decided before implementing solution for this bug, (snip)
> 
> Decided? By whom, what was decided?

Wait WADA, language misunderstanding, no reason to worry.
I never said "it was already decided", I only said "we need to decide if we want dual or triple pref for unknown=... before implementing this bug" because it has consequences for implementation.
Dual pref -> boolean implementation as suggested by WADA here is possible.
Triple pref -> boolen implementation as suggested by WADA here is not possible.

Comment 9

[Thomas D. (:thomas8)]

(In reply to WADA from comment #6)
> To aceman.
> Please change pseudo code to correct patch and land it, before this bug will
> be filled by flood of complaints, as done in Bug 1204379 and Bug 1210244.

I don't think WADA it's correct procedure to instruct Acemen to just land YOUR idea of an unknown==dual-pref patch when both aceman and I have raised the point that we'd like to see "both" as another option which makes it unknown==triple-pref.

I don't see "flood of complaints", I only see targeted discussion here, and a single digressing user in comment 5 who can be forgiven because he's not privy to our knowledge nor plans, so he's raising relevant points only in the wrong place. Plus he can't know our mood problem of finally getting done with this. I do see, more recently "flood of comments by WADA > flood of comments by myself". Maybe that's something to start worrying about... ;) I think we also need to give others including ourselves some time to catch up, digest, and reflect. Solutions are very close, Aceman is very cooperative and relaxed, even Ben has made the main concession to make Auto-Downgrade optional, so I'm not much worried.

WADA, maybe it's time for a little break to cool down, I also took some time out before going back into business on these bugs.

Comment 10

[Thomas D. (:thomas8)]

(In reply to Dan Pernokis from comment #5)
> For the case of all-plain-text recipients, I still have concerns about how
> HTML is handled (i) during preparation and (ii) storage of the message after
> sending.  I've mentioned this in other related bugs and seems to get ignored.

Hi Dan, I thought I had answered to you somewhere already, but maybe not, too many comments... ;)

> (1) What happens if I prepare a fancy-looking (ie- HTML) message but all
> (perhaps only ONE) current recipients happen to be plain-text, and I save
> the message in draft to be recalled and sent later?  When re-opened, is the
> message still formatted, or has it been down-graded to plain?  This matters,
> because I might want to add more recipients, any of whom could prefer HTML. 
> (And it could easily happen if my initial list included only one recipient
> that happened to prefer plain-text, such that "all" one recipients prefer
> plain.)  Downgrade to plain-text -- if it is going to happen -- must not
> occur until all user edits are complete and the actual SEND process begins.

No message must ever be downgraded (unless explicitly requested) before sending.
Saved drafts must preserve, and do preserve all formatting afasik, even when all recipients prefer plaintext. If formatting is not preserved in drafts, please file a bug.

WADA and I have suggested multiple strategies to prevent unwanted downconversion when sending:
- implement pref to switch of Auto-Downgrade completely (necessary because message-centric auto-downgrade occurs before recipient-centric auto-detect)
- implement global pref where user decides: prefers-unknown==prefers-plain||html||both (WADA does not want both, Aceman and I do). this will enable users to tilt the balance in favor of html.
- implement default choice of delivery format for composition (at least global, otherwise ideally per-identity), so when you start your message, you can default to any of:
Auto-detect || plain(&ask) || html || both.
- split Auto-Detect-Send-Options to allow separate user-defined action for recipient scopes of allPlain vs. somePlain.

> (2) After my fancy message has been sent, even if "all" recipients prefer
> plain, how is the message stored in my SENT folder?  If I went to the
> trouble of formatting, I'd like that to be retained please, for possible
> forwarding or re-sending (to HTML clients, for example), and certainly for
> printing and archiving.  I think users would always want the SENT copy to be
> as they created it (including any formatting) and not how TB eventually sent
> it out (perhaps plain-text only).

Well, I disagree on that one. We should do everything to let you chose the correct send format freely, without any hindrance. But once the message is sent (as long as we only send the same message to recipients with different preferences, which makes sense), we should only save the copy which was really *sent*. It's called *Sent* folder, so we can't keep messages here which you have never sent in that format, which would be grossly confusing even for yourself. You would never know in which format the message has actually gone out or not.
Your scenario: compose html, send plaintext, but want spare copy of html composition after sending
Please do this:
At any time before sending, save msg as draft.
Then copy fully-formatted draft message from draft folder into another folder.
Send.
Reuse fully-formatted draft copy as you please (e.g. "Edit as new").

> Personally, I still prefer default preference to be "both", but I can settle
> for "HTML-only" if it doesn't cause problems downstream.

That's why aceman and I want unknown==both as an option.
We'll probably continue to default to both for all mixed or allPlain cases.
We'll hopefully default to HTML-only if unknown==HTML and allHTML case. I recommend that as a default, but others might disagree. If they do, default will be both also for that case.

My creed: Different users --> different needs. Let the user decide.
Hence I'm advocating for those user prefs where user can choose whichever behaviour he likes best.

> As for WADA Comment #1:
> >> User usually keeps Prefers=Unknown of almost all Contacts in All Address Books.
> I expect there are indeed a lot of recipients with "unknown".  People have
> hundreds (or thousands) of addresses in their Collected Addresses book, many
> of them treated as permanent because they are there.  Likely most of them
> were added automatically ("collected"), with default set to "unknown",
> likewise automatically.  The majority of people don't clean up and purge
> their address books as they should, probably because they don't know.

Yes, hence the need for global pref which allows disambiguating "unknown" into "known" (plain | html | both). Exactly this bug.

Comment 11

[Thomas D. (:thomas8)]

Dan, let's try not to hijack WADA's bug, he's a bit allergic against too many comments right now, and for good reason in general, although he also adds many comments himself ;) Email me privately if there's anything else.

Comment 12

[Thomas D. (:thomas8)]

(In reply to WADA from comment #3)
> (In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment
> #2)
> > FTR, Aceman and I agree that we must also offer flavor of unknown==both
> > (multipart/alternative plaintext+html).
> 
> Thomas D., please add such comment after you did following which I wrote in
> Bug 1210244 Comment #173.
> > Please enhance Send Options and Address Book for "Both" by yourself, which both of you want, before saying complaint to me.

Nobody complained. Calm down, please.
If you're trying to prevent any discussion of "unknown==triple pref inluding both" on your bug here which suggests "unknown==dual pref excluding both", it's not possible.
You're not owner of your bug, nor owner of discussion. It's necessary discussion *before* implementing your proposal here, because we need to decide what we want first.

> > Please implement Prefers=Both in Address Book and "Both Domain" in Send Options.

I'm not sure if that's needed, and here's why:
"Unknown" is current value possible for each recipient.
But "Unknown" is meaningless in itself, we cannot send "Unknown".
So we let user define translation of "unknown".
One possible translation is "Both".
With that, user can set "Both" for all recipients of "prefers-unknown".
So "Both" value is practically implemented.

What is not possible with my model is to have general "Unknown==html" AND make some exceptions for individual recipients where "unknown==both". Is that a scenario which you think should be covered?
You really think we can only do all-or-nothing?

Please avoid using hidden tactics, just tell us clearly what you think and why. But never tell us to stop talking before we have even started.
Also, allowing unknown==both is not prejudicial for lateron implementing Both-domain, or both-per-recipient. I think.

> Please don't confuse following.
>  (a) (a-1) HTML Domain/Text Domain in Send Options panel with (a-2)
> Prefers=HTML/Text in Address Book
>  (b) (b-1) Delivery Format=Both/HTML/Text menu and (b-1) Ask/Both/HTML/Text
> for action/format in the panel

I don't see myself in danger of confusing these, but maybe I'm wrong.
If "both" is a legitimate send format, then there's nothing wrong with allowing "unknown==both", which actually fills that gap in per-recipient preferences quite nicely without doing full implementation of per-recipient "both" or per-domain "both" preference.

Comment 13

[Thomas D. (:thomas8)]

For this bug, here's my proposal how to implement send logic pref for unknown== plain || html || both (simple way of providing the "unknown==both" case which WADA doesn't like for reasons==unknown so far...)

For more background, and full table of recipient scope combinations including "both" before conflation as below, please see PDF attachment 8675716 [details].

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from bug 1210244, comment #186)
> WADA, Aceman, FYI:
> 
> My full proposal (allowing unknown==both; separate send options for allPlain
> vs. somePlain recipient scopes) can still work with very simple send logic
> (each 'if case' exits the logic with 'return'):
> 
> if autoDowngrade==true && convertible::Plain    send Plain
> if (allHTML)    send HTML
> if (allPlain)   use SendOptions1 (default: both) [send option for allPlain]
> if (somePlain)  use SendOptions2 (default: both) [send option for somePlain]
> if (someBoth)   send both
> (These send logics cover all scopes, so we must NOT default to asking after
> this)
> 
> Note:
> autoDowngrade==pref(AutoDowngrade)
> (somePlain) scope covers all combinations involving any recipient who
> prefers plaintext:
> - somePlain & someHTML
> - somePlain & someHTML & someBoth
> - somePlain & someBoth
> (someBoth) scope covers (allBoth), too
> 
> Pseudo code for setting the new send logic variables:
> if recipient-preference==plain is found --> somePlain=true
> if recipient-preference==unknown-both is found --> someBoth=true

Comment 14

[Thomas D. (:thomas8)]

NI WADA on comment 12, comment 13.

1) Do you think unknown==both can only be implemented if we also, and at the same time, implement per-domain preference "both", and per-recipient preference "both"? If yes, why? (I think not, please read my comment 12).

2) Anything wrong with my simple send logic of comment 13, including unknown==both?
It will not be one-liner, but just a few more lines, and aceman is willing and able if we agree on the way forward. Even I could code that myself, but I'm more inclined to defining good UX, and Aceman is faster in coding, and less inclined for UX discussion :)

Comment 15

[Thomas D. (:thomas8)]

WADA, FYI:

One possible misunderstanding between WADA and (Aceman and myself, ThomasD).

WADA surprisingly said "if you want to implement unknown==plain|html|both (triple pref), then also implement per-recipient preference for "both" and per-domain preference for "both".

Possible Explanation:
Perhaps WADA assumes that setting global unknown==xxx will actually hard-change the per-recipient (per-card) preferences forever, for new and maybe also for existing contacts? So that affected cards will no longer be pref-unknown, but physically (per-card) pref-plain, pref-html, or pref-both?

But my understanding is that we keep per-recipient pref of "unknown" untouched and user can at any time change the global translation for that. So if it's just a global translation, which can be changed at any time, I don't see any need to also provide per-recipient preference for "both" and per-domain preference for "both", and even if we actually want that, we can always implement that later without any problems and unhindered by the current three-way implementation proposal for this bug.

Comment 16

[WADA:World Anti-bad-Duping Agency]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #14)

As I alresdy wrote in Comment #7, I stopped to touch this bug any more. Please don't ask me comment any more.

Comment 17

[Dan Pernokis]

Reply to Thomas Comment #12...

>> Well, I disagree on that one. ... But once the message is sent ... we should 
>> only save the copy which was really *sent*. It's called *Sent* folder...
Well, on reflection, I disagree with myself on this one too!  You're right, sent should be "as actually sent out".  (But could you save both formats if you did a downgrade?  The original format is still in hand at that point so should be possible.  There are times a recipient may be missed and we need to forward a copy, and maybe this is someone who wants HTML and could benefit from the formatting.)

>> Saved drafts must preserve, and do preserve all formatting afasik...  please file a bug.
See my Bug #1095629 -- the email editor was invoked by an external process (Windows Explorer's "send to email recipient").  The formatting was lost when saved to draft and re-opened later -- and WADA confirmed the process in that bug's com #23.  (Apparently a different variation of the problem, but from UX pov, still a change from what-I-prepared vs what-was-actually-sent.)

Comment 18

[Thomas D. (:thomas8)]

-> Incomplete. Reporter declared in comment 16 he will no longer "touch" / cooperate on this bug, and won't answer any questions. Legitimate needinfo of comment 14 was deliberately ignored. Comment 14 was trying to get clarity about dubious claims of reporter about massive implementation needs when slightly different solution (triple pref) is implemented instead of his preferred solution (dual pref). Comment 14 also requested information if there's anything wrong with alternative proposal. Without such answers, it cannot be evaluated if this bug is wanted/sustainable/best solution or not.

Comment 19

[Thomas D. (:thomas8)]

WADA, fyi.

The only solution which you are trying to push for this bug certainly works to address the main issue under the current circumstances of the code, with minimal changes. But it's not very flexible or acceptable solution. Here's why:

However, I think we agree that we want default of Unknown==html (or perhaps both). Unknown==plain is violating common sense and simply not true as a default intention for most users; and setting unknown==plain only to restore Auto-Downgrade feature for "unknown" would create more confusions and more problems again for correct and transparent auto-detect.

If unknown==html (default), then unknown==allHTML case.
So with your proposal here, convertible::plain is always ignored and we'll force sending HTML even when the message is convertible, and even if user actually wants Auto-Downgrade for messages of convertible::plain & unknown.
Iow, Auto-Downgrade is forcibly switched off for allUnknown case.

From developer comments on Bugs (Magnus, Joshua, Ben), it's very unlikely that such unchangeable default of force-bypassing Auto-Downgrade will be accepted:

Joshua, Bug 1210244 Comment 25:
> I consider it a minimum, non-negotiable requirement than any change in this
> arena preserve the property that, in a default install, the user can send an
> email to a previously unknown recipient (and reply to a plaintext email)
> that was composed in the HTML editor that used no extra formatting, and we
> will send that email as a plain text email without prompting the user.

Magnus, Bug 1210244 Comment 19:
> Comment on attachment 8669272 [details]
> (already rejected by Ben, don't comment on it, please) {Auto-downgrade only
> for allPlain} - Pseudo one-liner patch created by altering aceman's patch
> attached to Bug 1204379
> 
> In addition to not fixing the dataloss case, you're basically making
> plaintext a no-op even if there's no formatting at all.

(Wada's proposed patch here will still Auto-Downgrade for mixed cases of prefers-plain & prefers-html, but never for all-unknown cases if unknown==html.)

Ben Bucksch, Bug 1210244 Comment 50:
> Comment on attachment 8669272 [details]
> (already rejected by Ben, don't comment on it, please) {Auto-downgrade only
> for allPlain} - Pseudo one-liner patch created by altering aceman's patch
> attached to Bug 1204379
> 
> This disables the whole code that tries to detect whether we can send as
> plaintext or not, based on whether the content of the email is inherently
> plain text or not.

So in its strict form, this bug is probably wontfix by those devs mentioned.
I don't have strong feelings in favor of Auto-Downgrade, but I think it's OK if it's optional and easily controllable from primary UI.

So if we want auto-downgrade to work for cases of unknown==html, then we need to include allHTML scope into Auto-Downgrade scope, which is more consistent anyway, to clearly separate message-centric vs. recipient-centric behaviour.

Comment 20

[Wayne Mery (:wsmwk)]

closing incomplete really seems to me quite heavy handed. please don't do that. 
especially given that aceman hasn't commented - at his convenience.

Comment 21

[WADA:World Anti-bad-Duping Agency]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #19)

As I said, I don't touch any more, and this bug is already closed.
If a part of my pseudo code is useful for you, please morph my pseudo code freely as you like, as you want,
But never use/refer my "Conclusion of this bug" of Bug 1210244.
This is my document and is never code which I gave Mozilla community. I have copyright.
Call Gerv for it?.

I thought separate/crisp bug is needed for review by aceman,
So I merely opened this bug just before following Bug 1210244 Comment #172 from aceman on 2015-10-17.
> (v6) Conclusion of this bug
> (snip)
> But you guys need to file these as simple bugs with clear descriptions
> and no fights/discussions about what actually is to be done (what the proposal actually is).
I won't touch this bug any more, and this bug was alreasy closed by someone, so there is no need of review by anyone any more.

Comment 22

[WADA:World Anti-bad-Duping Agency]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #20)

There is no need of re-open.
I won't touch this bug any more, and I've canceled request to aceman.

Comment 23

[WADA:World Anti-bad-Duping Agency]

To Wayne.
I want to delete files I uploaded to bmoattachments.org(attachment of a bug of bugzilla.mozilla.org).
How can I do it?
Or ownersip/copyright of my document is automatically transfered to Mozilla Foundation by my attaching to a bug at bugzilla.mozills.org?

Comment 24

[WADA:World Anti-bad-Duping Agency]

(Off-Topic)

To Thomas D. (no need of response)

What occurred.

(1) 2015-10-17 open of Bug 1215791(this bug)
(2) 2015-10-17 Bug 1210244 Comment #172 from aceman
> (v6) Conclusion of this bug
> (snip)
> But you guys need to file these as simple bugs with clear descriptions
> and no fights/discussions about what actually is to be done (what the proposal actually is).
(3) 2015-10-17 Bug 1210244 Comment #173 from WADA
> In reply to aceman
> See bug 1215791, please.

After it, even though aceman's comment,
even though I said "Prefers=Both is not entity in Address Book" several times in Bug 1210244,
even though I said "please enhance Address Book and HTML/Text Domain setting by yourself" in this bug,
you repeated following in this bug.
  Both is needed in new prefs for interpretation,
  even though the new prefs is for
  "Prefers is Unknown in Address Book and HTML/Text Domain is unknown in Send Options panel".
Further, you attacked my requesting to aceman based on Bug 1210244 Comment #172.
This is a kind of "DoS attack to a bug by flood of comments" or a kind of "project to make a bug hard-to-read/understnd/follow by wrong comment at wrong place" which you like.

Because I merely presented a simple/minimum solution to aceman according to his request of Bug 1210244 Comment #172,
when I saw DoS attack / the project in this bug, I stopped to touch this bug, and passed controll to aceman.
I can't afford to such DoS attack / project by you in this bug.
It's obvious that you never read Bug 1210244 Comment #172 from aceman on 2015-10-17, even though you added many comments under it. 
It's obvious that you ignored my comments about new pref.
It's perhaps because it's different from your opinion or want.
I can't afford to your "adding comments without reading/understanding previous comments" in this bug.

Even though you posted bug 1210244 comment #184,
(an evidence of that you understood the solution),
and even thoigh I respect your effort on creating mock-up of panel,
I can not admit your interfering with analysis/evaluation of a solution in this bug.

Comment 25

[WADA:World Anti-bad-Duping Agency]

To Wayne.
I wanted to protect my documents, so I set "Restrict ...", then Securty flag was set.
How can I restrict access to this bug without Security flag?

Comment 26

[:aceman]

I still want to implement this fix (make option to set Unknown=HTML/Both/plain), so I am not sure why this bug is closed, what documents is WADA trying to hide. If this is not the bug for implementing that options, which one is it?

Comment 27

[Wayne Mery (:wsmwk)]

I'm opening this bug up for aceman.

Can we all agree to simply keep/limit comment activity for now to be between any patch author and the patch reviewer?

Thanks



(In reply to WADA from comment #23)
> To Wayne.
> I want to delete files I uploaded to bmoattachments.org(attachment of a bug
> of bugzilla.mozilla.org).
> How can I do it?
BMO folks can do it. I cannot.

> Or ownersip/copyright of my document is automatically transfered to Mozilla
> Foundation by my attaching to a bug at bugzilla.mozills.org?
If you want additional in formation on this you'll need to as a module owner or someone like gerv

Comment 28

[WADA:World Anti-bad-Duping Agency]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #27)
> I'm opening this bug up for aceman.
> 
> Can we all agree to simply keep/limit comment activity for now to be between
> any patch author and the patch reviewer?

No. I disagree. I never want to keep my name in bug opener's field for this issue.
I can not forgive interfere.

To aceman, after read this bug, please close this bug immediately, and please open separate bug if you need to do something on my pseudo code.

> (In reply to WADA from comment #23)
> > To Wayne.
> > I want to delete files I uploaded to bmoattachments.org(attachment of a bug
> > of bugzilla.mozilla.org).
> > How can I do it?
> BMO folks can do it. I cannot.

How/to whom, can I request it?

> > Or ownersip/copyright of my document is automatically transfered to Mozilla
> > Foundation by my attaching to a bug at bugzilla.mozills.org?
> If you want additional in formation on this you'll need to as a module owner or someone like gerv

The documen I call is not code nor Mozilla's document. It's text document for explanation about phenomenon, issue and so on which I created. Upload to B.M.O was my fault. I shouldn't have uploaded to B.M.O, where interfere is permitted.
I don't want to permit access to it from any user of B.M.O any more.  
I can not forgive interfere.

Comment 29

[WADA:World Anti-bad-Duping Agency]

(In reply to :aceman from comment #26)
> so I am not sure why this bug is closed, (snip)

Please ask to who intentionally closed this bug on 2015-10-19, on purpose, not to me.

> I still want to implement this fix (make option to set Unknown=HTML/Both/plain), (snip)

Still saying Both... :-)  Please freely morph as you like.

> what documents is WADA trying to hide.

All documents which I uploaded in bug 1210244 except psuedo code. (currently, obsolete flag is set)
I never want access by people who interfered any more.
I believe that my psuedo code only is sufficient for you.

> If this is not the bug for implementing that options, which one is it?

AFAIK, there is no such bug for it. Please open separate bug.

Comment 30

[WADA:World Anti-bad-Duping Agency]

Because aceman posted comment to this bug, he can read this bug any time, and my pseudo code only is sufficient.
I close this bug again, to keep status when inrerefered.

aceman, please freely morph my patch with Thomas D., as you like, as you want.

My pseudo code is merely an example of minimum change of "one-liner patch which is successor of your inital one-liner patch" + "essentially 5 to 10 line change for converting 'Prefers=Unknown' and 'HTML Domain/Text Domain is unknown' to HTML or Text using a new pref".
Even with this minmum change, if user sets default=HTML, any "HTML mail to Prefers=Unknown recipients only" is sent as text/html always because of allHtml=true, regardless of CSS Style use, regardless of tag use.
I never believe "mail creator who wants to fully utilize CSS Style and creates simple HTML always" fully utilize Prefers=Text in Address Book. If no Prefers=Text Contact in Address Book, problem can't occur even with minimum change, even if Convertble=Yes is still returned for CSS Style case.

Please freely add Both or BothBoth or BothBothBoth. Please freely add any new pref. Please freely enhance Send Options panel and its backend code.
How about embedding Adobe Acrobat in enhancement and convert to PDF in enhancement? PDF is far beatiful than HTML and font can be embed in document. If PDF attachment, mail creator is safficiently satisfied with beatiful document and text/html vs. text/plain war won't occur.

However, aceman, please avoid overkill or excessive work in this kind of issue.

Comment 31

[WADA:World Anti-bad-Duping Agency]

This is last comment from me to you in this bug.

To aceman, please consider following.

About your "Both".

After the minimum change, Prefers=Text/Text Domain relevant cases are following.
  (i)   if(allPlain&&Convertible)     send text/plain
  (ii)  if(allPlain&&Not-Convertible) send text/plain
  (iii) if("HTML+Text"&&Convertible)     use Send Options => no problem, because user can set
                                                             but same option as (iv)  
  (iv)  if("HTML+Text"&&Not-Convertible) use Send Options => no problem, because user can set
                                                             but same option as (iii)  

If default=HTML, (i)/(ii) occurs only when all recipients are Contact of Prefers=Text in Address Book.

This is absolutely same as current situation, and this logic is used for long time since initial of Auto-Detect.
Do you know actual bug reports on (i)/(ii)?
All reports by a people is Prefers=Unknown case, isn't it?
When the people started to shout "data loss" for (i) and/or (ii) was after he saw table for broken doen logic, wasn't it?

I think user of following type is not so many, rather exceptional.
   Even though he know recipients are Prefers=Text/Text Domain recipients.
   creates "simple HTML or Complex HTML with fully utilizing CSS Style",
For recipients, text/plain only is sufficient, isn't it?
Why mulipart/alternative mail should be sent to Prefers=Text/Text Dmain recipints?
It's merely an annoyance for Prefers=Text/Text Dmain recipints, isn't it?

"Repeating Both, Both, Both" sounds for me being monomaniac.

If default=Text, many cases fall into (i)/(ii).
Do you think number of users of following type who set default=Text is many?
   Even though he know recipients are Prefers=Text/Text Domain recipients.
   creates "simple HTML or Complex HTML with fully utilizing CSS Style".

"CSS data is lost!" in (i)/(ii) is absolutely irrerevnt to recipients of email, isn't it?
Email is for recipient, isn't it?
Email is never for satisfaction of HTML mail creator, is it?

I'm never opposite to that you freely enhance for prefs=Both which you deeply loves.
But, please remeber that "new pref of default for Unknown in the minimum change" is borrowed from Bug 56834 opened on 2000-10-16.
i.e. prefs is shared between this minimum change and enhancement by Bug 56834.
This is reason why I said you "please enhance Address Book first for your Both".
We can freely use new prefs, but consistency with other feature is also important.
And, as pretty easily known by logic, current Prefers=HTML/Prefers=Text in Address Book corresponds to HTML Domain/Text Domain in Send Options panel.
i.e. Prefers=HTML/Prefers=Text in Address Book is "per email address HTML Domain/Text Domain setting".
So, consistency with HTML Domain/Text Domain setting is also important.
If Both will be introduced, definition change of relevant terms is required, and documents should be updated according to change.

I don't believe that such relatively large changes is needed now for merely a part of users.

Comment 32

[WADA:World Anti-bad-Duping Agency]

Ben, see "pseudo code" pointed in User Story of this bug, please.
We are trying to do such change. This is "revenge to you" version :-)

Comment 33

[WADA:World Anti-bad-Duping Agency]

Ben, I think that even by the minimum change + prefs=HTML, almost all shouting of "massive data loss" by a people will stop, because almost all his case is "recipent(s) is Prefers=Unknown only && many CSS Style is used for simple HTML" case(currently, Convertible-to-text=Yes).
If all his cases falls into allHtml case, there is no need of "CSS Style support in Convertble check", because aConvertible value is irrevant.
What do you think?
Next shouting of "massive data loss" is for "recipent(s) is Prefers=Text only && many CSS Style is used for simple HTML or complex HTML && Not-Convertible after CSS attrbute support in Convertble check logic"?

Comment 34

[:aceman]

(In reply to WADA from comment #31)
> "CSS data is lost!" in (i)/(ii) is absolutely irrerevnt to recipients of
> email, isn't it?
> Email is for recipient, isn't it?
> Email is never for satisfaction of HTML mail creator, is it?
Well, it looks to me all the big problem and all these bugs are actually about this. That the recipient wants to decide what is sent out and what tiny formatting is preserved. I think that is also what Thomas pushes (the message-centric vs. recipient-centric format determination).

> I'm never opposite to that you freely enhance for prefs=Both which you
> deeply loves.
> But, please remeber that "new pref of default for Unknown in the minimum
> change" is borrowed from Bug 56834 opened on 2000-10-16.
> i.e. prefs is shared between this minimum change and enhancement by Bug
> 56834.
> This is reason why I said you "please enhance Address Book first for your
> Both".
The AB already contains a third state (which is "Unknown, or unset"). So why not tie Both to this Unknown by default. And some people can set that defaut to HTML (only) or plain.

Comment 35

[:aceman]

(In reply to WADA from comment #32)
> Ben, see "pseudo code" pointed in User Story of this bug, please.
> We are trying to do such change. This is "revenge to you" version :-)

No "revenge" versions please:) Just keep Ben's behaviour and add possibility to behave differently for people that want it.

Comment 36

[WADA:World Anti-bad-Duping Agency]

(Off-Topic)

(In reply to :aceman from comment #35)
> No "revenge" versions please:) 

”Revenge of the Jedi” is original title of "Return of the Jedi". It was changed just before Movie release.
In Japan, ”Revenge of the Jedi” in Japanese was used upon Movie release, because impact of "revenge" is far bigger than "return". 
So, please change to "return" just before you land patch :-)

Comment 37

[:aceman]

(In reply to WADA from comment #36)
> In Japan, ”Revenge of the Jedi” in Japanese was used upon Movie release,
> because impact of "revenge" is far bigger than "return". 
That is true in many other languages. Just that it also has a negative aspect to it.

Comment 38

[WADA:World Anti-bad-Duping Agency]

(In reply to :aceman from comment #37)Hmm

Hmm, "negative aspect" was reason of changing title, culture seems different betweem US and other small countries like Japan.

Comment 39

[WADA:World Anti-bad-Duping Agency]

aceman, please don't misunderstand Ben.
Ben is good friend for old boys like me, who is stubborn old man doctor.
Ben is good Grandpa for young *ordinal* peoples.
Ben is stubborn old man doctor for kids ;-）
I tweated "Damn, this stubborn old man doctor, Ben" two times in mind in the past :-)

Comment 40

[WADA:World Anti-bad-Duping Agency]

Sorry, typo. tweated => tweeted

Comment 41

[:aceman]

Let's hope Ben understands your multicultural jokes :)

Comment 42

[WADA:World Anti-bad-Duping Agency]

(In reply to :aceman from comment #34)
> The AB already contains a third state (which is "Unknown, or unset").
> So why not tie Both to this Unknown by default.
> And some people can set that defaut to HTML (only) or plain.

Oh, your "Both" looks far different from "shouting Both, Both, Both" by someone.

If Prefers=Unknown is kept in Address Book by deafult(I think Bug 56834 is not needed any more if minimum change or your ehancement will be implemented), your enhancement for "Both in new pref" is reasonable eanhancement, as far as such enhancememt for Both is mandatory, although definition change of Prefers in Address Boook is needed, and clear eparation from HTML Domain/Text Domain is needed.

Comment 43

[WADA:World Anti-bad-Duping Agency]

(In reply to :aceman from comment #34)
> I think that is also what Thomas pushes (the message-centric vs. recipient-centric format determination).

Oh, sorry, I thougt you also are shouting "massive data loss!!!" even though you use text mail in daily use like me :-)
Please avoid overrkill in world of this old/well known issue.
Please don't be dragged to loud voice of a someone in B.M.O.

Comment 44

[WADA:World Anti-bad-Duping Agency]

Mock-up of future Send Options panel created by Thomas D. in Bug 1210244.
  Attachment #8672330 [details]
  Attachment #8672688 [details]
  Attachment #8673807 [details]

Comment 45

[WADA:World Anti-bad-Duping Agency]

Sorry, forgot 4-th one.
  Attachment #8675716 [details]

Comment 46

[WADA:World Anti-bad-Duping Agency]

(Replacing comment #32)
Name of a solution was changed just before open to public.
> Ben, see "pseudo code" pointed in User Story of this bug, please.
> We are trying to do such change. This is "Return of the Wada", "We returned!, Ben" version.

Comment 47

[Thomas D. (:thomas8)]

I have a proof of concept patch for nsMsgCompose.cpp(In reply to :aceman from comment #26)
> I still want to implement this fix (make option to set
> Unknown=HTML/Both/plain), so I am not sure why this bug is closed, what
> documents is WADA trying to hide. If this is not the bug for implementing
> that options, which one is it?

FYI: I have a proof of concept patch for the auto-detect algorithm in nsMsgCompose.cpp which consults pref for Unknown=HTML|Both|plain.

Comment 48

[Tony Mechelynck [:tonymec]]

(In reply to WADA from comment #36)
> (Off-Topic)
> 
> (In reply to :aceman from comment #35)
> > No "revenge" versions please:) 
> 
> ”Revenge of the Jedi” is original title of "Return of the Jedi". It was
> changed just before Movie release.
> In Japan, ”Revenge of the Jedi” in Japanese was used upon Movie release,
> because impact of "revenge" is far bigger than "return". 
> So, please change to "return" just before you land patch :-)

IIRC, in German, "revenge" is "Vergeltung" as in "Vergeltungswaffe", the full name of the infamous V1 and V2 weapons of WW2. This may make the word particularly offensive in that language, especially in a military (incl. Star Wars) context, except of course with Nazi nostalgics and other neo-Nazis.