44494 - [SM] Checkbox to remember the decision the user makes in the askSendFormat dialog so that we don't ask again

Status: NEW

(SeaMonkey :: MailNews: General, enhancement)

Description

[Ben Bucksch (:BenB)]

Add a checkbox to apply the same decision for the askSendFormat dialog ("Send as
plaintext or HTMl or both?") in the future in the same situation.

This is not the same as our existing pref in the Format prefs pane: That pref
disables "intelligent send", i.e. if you set this to HTML, *all* mails will be
sent as e.g. HTML, even if that makes not much sense.

You might want to send all msgs containing no formatting as plaintext, but all
others as both HTML and plaintext.

We might have to change the existing pref, especially the dialog, as well in
order to not confuse the user.

Comment 1

[Ben Bucksch (:BenB)]

mass-accept

Comment 2

[Ben Bucksch (:BenB)]

Changing personal priorities. Giving away most of my bugs :-( (reassigning to
default owner).

I will still track these bugs closely. If you need my input, feel free to ask me.

New owner: Please do *not* close these bugs (as WONTFIX or whatever you may
find) unless they are fixed. Rather, reassign to <[e-mail]>, if you
don't want to work on them.

Comment 3

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 91613 has been marked as a duplicate of this bug. ***

Comment 4

[Jean-Francois Ducarroz]

over to varada

Comment 5

[Sheela Ravindran]

change qa contact ->esther

Comment 6

[David Grant]

Does this feature request include a "remember this decision" case for individual
e-mail addresses?  For example if I write to my friend at [e-mail], if
I select HTML will it remember this decision for him only?  In other words, will
it set his formatting preference in my address book to HTML or plaintext or
whatever?

Comment 7

[Ben Bucksch (:BenB)]

*** Bug 139209 has been marked as a duplicate of this bug. ***

Comment 8

[(not reading, please use [e-mail] instead)]

taking all of varada's bugs.

Comment 9

[Scott MacGregor]

no pref, we'll just remember it in the AB.

Comment 10

[Ben Bucksch (:BenB)]

xref bug 136502

Comment 11

[Scott MacGregor]

Attachment: patch

I still need to:

1) test and re-test
2) consider doing a typef for nsIAbPreferMailFormat's unsigned long to clean up
the idl and C++
3) figure out if I did the mapping right between the ldap/vcard attribute
xmozillausehtmlmail (true / false) to (unknown, plain, html, both).
4) verify what happens with mixed formats, send email to a,b,c:  a uses plain,
b uses html, c does both.
5) decide if it is ok that we won't remember if we don't collect.

Comment 12

[Scott MacGregor]

...and re-read all the relevant bugs (thanks benb)

Comment 13

[Ben Bucksch (:BenB)]

mscott, I don't see any "remember" checkbox in the patch. What about the case
where I decide to send a particular mail as HTML, because it's worth it in this
case (much formatting etc.), but generally want to send plaintext, even to that
recipient? Or if I have a larger number of recipients, and I know that some of
them want plaintext, but some can recieve HTML, so I decide to plaintext as
lowest common determinator in this case?

Comment 14

[Scott MacGregor]

> mscott, I don't see any "remember" checkbox in the patch. 

We're just going to automatically remember.  to undo your decision, you can
change the value in the addressbook (using the edit card dialog)

> What about the case
where I decide to send a particular mail as HTML, because it's worth it in this
case (much formatting etc.), but generally want to send plaintext, even to that
recipient? Or if I have a larger number of recipients, and I know that some of
them want plaintext, but some can recieve HTML, so I decide to plaintext as
lowest common determinator in this case?

I need to see what happens in the mixed scenario.  (see "4) verify what happens
with mixed formats, send email to a,b,c:  a uses plain, b uses html, c does both."

if you've already remembered that someone prefers html, plain, or both, that
decision will not be overriden.

the goal here is to make things better by default, and I think remembering the
decision is better.

Comment 15

[Ben Bucksch (:BenB)]

> to undo your decision, you can
> change the value in the addressbook (using the edit card dialog)

I don't think any user would know/remember that or even see a connection between
the askSendDialog and the address book card dropdown.

Use case: I send a long, structured post to a <[e-mail]>, so
I choose plaintext+HTML in the askSendFormat dialog. But that doesn't mean that
I'll want to always send plaintext+HTML to the newsgroup from now on. And I
don't want to have to go to the address book and set the pref - that's
inconvient and non-obvious.

> I need to see what happens in the mixed scenario.

I'd not remember anything in that case. If the user chose plaintext, it doesn't
mean that all of the recipients should always get plaintext from now on. If the
user chooses HTML, it doesn't hold true always either (similar to the use case
above).

Comment 16

[Scott MacGregor]

> I need to see what happens in the mixed scenario.  (see "4) verify what happens
> with mixed formats, send email to a,b,c:  a uses plain, b uses html, c does both."

in this scenario, you would get the prompt, because a prefers plain text.

but, since all three already have a preference, nothing would change in the AB.

we only save changes to the AB if the previous preference was unknown.

> 5) decide if it is ok that we won't remember if we don't collect.

I've made it so we will remember the preference, even if we disable autocollect,
but only if there is a card, and the current preference is unknown.

I still need to double check the xmozillausehtmlmail stuff.

Comment 17

[Ben Bucksch (:BenB)]

> in this scenario, you would get the prompt, because a prefers plain text.

I meant the case where all are "unknown" (to us), but the person a can only read
plaintext, while person b prefers HTML. User must send as plaintext, but you
should not set the card for b to plaintext.

Comment 18

[Scott MacGregor]

new patch coming, when editing vCards, we can't show the "both" menuitem for
prefered format, as xmozillausehtmlmail is a boolean.

also, I think I broke addressbook export, working on it...

Comment 19

[Scott MacGregor]

> also, I think I broke addressbook export, working on it...

yikes, it's broken but it's not me.  but I'm working on it.

we call Init() with a null parent.

rv = filePicker->Init(parentWindow, title, nsIFilePicker::modeSave);
  NS_ENSURE_SUCCESS(rv, rv);

Comment 20

[Scott MacGregor]

we're no longer calling SetDocShellWindow()

Comment 21

[Scott MacGregor]

I've got a fix for the "addressbook export is broken" bug, and some code cleanup
to do it a better way than having a weak ref to the doc shell.

patch coming...I'll log a new bug on "addressbook export is broken".

Comment 22

[Scott MacGregor]

Attachment: updated patch

Comment 23

[Scott MacGregor]

for the ldap import / export issue around the "both" format, here's what the
last patch does.

in ldif:  

xmozillausehtmlmail: false
or
xmozillausehtmlmail: true

so if you have unknown, we don't emit anything.  if you have both, I also don't
emit anything. 

I'll ping bienvenu for a review.

Comment 24

[Scott MacGregor]

found something that needs fixing.  

"a" prefs both, "b" prefs html, we should not get that dialog, but we do.

Comment 25

[David :Bienvenu]

great, thx for doing this!

while you're here:
+  [noscript] void collectAddress(in string address, in boolean aCreateCard, in
unsigned long sendFormat);

I think you can remove the [noscript], and change the arg names to aAddress,
aSendFormat... similarly for collectUnicodeAddress

is there a tab here?
+	const unsigned long both      = 3; 

NS_ERROR_FAILURE is so uninformative - what do you think about returning
NS_NOINTERFACE for the first and third calls here? and NS_ERROR_NULL_POINTER for
the second one? Or passing &rv to do_QueryInterface and returning the error rv
directly?
+  nsCOMPtr<nsIScriptGlobalObject> globalObj(do_QueryInterface(aParentWin));
+  if (!globalObj)
+    return NS_ERROR_FAILURE;
+
+  nsCOMPtr<nsIDocShell> docShell = globalObj->GetDocShell();
+  if (!docShell)
+    return NS_ERROR_FAILURE;
+
+  nsCOMPtr<nsIDOMWindow> parentWindow = do_GetInterface(docShell);
+  if (!parentWindow)
+    return NS_ERROR_FAILURE;

Comment 26

[Scott MacGregor]

thanks for the review comments, david.

as we discussed over email, I'm not going to add the "both" state. 

here's the new plan: 

1)  when asking, if the user chooses "both", remember "html" in the addressbook
for all those recipients who currently have "unknown".
2)  when asking, if the user chooses "html", remember "html" in the addressbook
for all those recipients who currently have "unknown".
3)  when asking, if the user chooses "plain", remember "plain" in the
addressbook for all those recipients who currently have "unknown".

Going forward, our users will see the ask dialog if they ever send to people
with "unknown" or a mix of unknown, plain and html.

I'll re-work the patch.

Comment 27

[Scott MacGregor]

Attachment: updated patch, per bienvenu's comments

Comment 28

[Scott MacGregor]

Attachment: patch

Comment 29

[Scott MacGregor]

fixed.

but see #243133 for a pre-existing (but bad) bug.

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

now that we are saving the preference, users will hit that bug more.

Comment 30

[Scott MacGregor]

> but see bug #243133 for a pre-existing (but bad) bug.

that bug is now fixed as well.

Comment 31

[Scott MacGregor]

to summarize:

When you now send and get that "send plain, html or both" dialog, we will
remember the decision you make in the addressbook. 

But we will only remember it for those email addresses that have "unknown" as
the prefered format.  (We will not override plain or html in the addressbook).

If you have "autocollect on send" turned off, we won't create a new card for the
email address if it doesn't exist after seeing the "ask send format" dialog, but
if a card does exist, and it has "unknown" as the format, we will remember the
format.

If you send as "both", we will remember "html".  (the choices in the ab card
dialog, and the edit vcard dialog are still unknown, plain, html.)

I've also fixed a bug where if you send mail to two people, and one prefers html
and one prefers plain text, we will prompt you for the send format.  (Before
we'd just silently downgrade to plain text)

Comment 32

[Ben Bucksch (:BenB)]

> If you send as "both", we will remember "html".

How is the msg sent the next time, then? If you send html the next time, that's
broken, because the whole point of both is that the recipient may not be able to
read HTML.

If there a reason not to add a "remember" checkbox? Most (all?) other dialogs
which remember the user's decision have this checkbox. And I think it's
necessary in this case for the reasons stated in comment 15.

Suggested wording:
[x] Remember this decision for this recipient in the address book card

(default on) this will allow the user to override, point out that we remember
the decision and will hint the user at where he can change the decision later
(that's currently not at all obvious).

Note that I used sigular for "recipient". If there are several recipients, the
checkbox should either not appear at all and be logically off, or the checkbox
should be (default off)

[ ] Remember this decision for all these recipients their address book cards

If you agree with this suggestion, but don't want to implement it yourself, I
will probably do it (in this bug or a new one, your choice), because the current
patch will break a few of my and other people's use cases and may cause problems
e.g. on mailing lists. I could work around it by not using the askSendFormat
dialog and instead using the Options menu in the composer, but arguably that
menu *should* behave the same as the dialog, i.e. also remember the decision in
the same way.


I have nothing against this feature in general, I agree that reducing the number
of appearances of the dialog is a very good think, *if* it does the right thing.
Compare bug 27933, which suggests another means to achieve the same, but I never
got around to implement it.

Comment 33

[Ben Bucksch (:BenB)]

> If you send html the next time,

s/html/html only/

Comment 34

[[e-mail]]

Ok, so I've only skimmed this patch, but it looks as if I can't even
one-time-override the send format without it getting saved as default?

Comment 35

[Mike Cowperthwaite]

I've been trying to verify this patch, but it doesn't seem to be working with
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040510

I have a recipient in my addr book whose preference is Unknown.  I compose an 
HTML mail to him (with formatting) and I get the HTML Question.  But no matter 
which selection I make, his preference is not updated.


I think Ben's suggestion in comment 32 for the "remember" checkbox is a very 
good idea; I particularly agree with changing its default state based on single 
vs. multiple Unknowns in the list.  See bug 243133 comment 7.

If the only Unknowns are recipients not already in the AB and address collection 
is turned off, the checkbox could be unchecked & disabled since it would have no 
effect.  But maybe that would be more confusing than stating we'll save 
something which doesn't actually get saved.

Comment 36

[Mike Cowperthwaite]

The preference *is* saved for Collected Addresses, tho.

Comment 37

[Scott MacGregor]

Attachment: supplemental fix for thunderbird

Comment 38

[(not reading, please use [e-mail] instead)]

see bug #245520.

remembering plain text is turning out to be problematic, so for now, I'm going
to make it so we only remember html.  you can still set plain text in the ab,
but we won't auto remember it.

Comment 39

[(not reading, please use [e-mail] instead)]

> I think Ben's suggestion in comment 32 for the "remember" checkbox is a very 
> good idea.

yes, I think that might be better.

after discussing it with mscott, for trunk (1.8a2) and tbird 0.7, I'm going to
disable the "remember" feature completely until I've sorted out the the remember
issue (with plain text) and added a checkbox.

related to this issue is the silent conversion issues to plain text (see bug
#246758 and bug #180997) and the issue of what the default should be
(ask,both,html,plain).

I'll attach a patch that basically reopens this bug.

Comment 40

[Ben Bucksch (:BenB)]

> I'm going to disable the "remember" feature completely until I've sorted
> out the the remember issue (with plain text) and added a checkbox.

Thanks, Seth!

Comment 41

[(not reading, please use [e-mail] instead)]

Attachment: patch to disable the "remember" feature, until I get it right.

Comment 42

[(not reading, please use [e-mail] instead)]

re-opening, maybe for 1.8 beta

Comment 43

[(not reading, please use [e-mail] instead)]

accepting.

on both trunk (1.8a2) and aviary 1.0, we no longer remember the decision (but
the plumbing still exists).

Comment 44

[Mike Cowperthwaite]

*** Bug 156021 has been marked as a duplicate of this bug. ***

Comment 45

[Mark Banner (:standard8)]

*** Bug 189471 has been marked as a duplicate of this bug. ***

Comment 46

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 47

[:aceman]

Was this actually ever landed? Or is the "disable" patch just for completeness if it lands prematurely?

BenB, Thomas, what do you think is still missing here?

Comment 48

[Thomas D. (:thomas8)]

(In reply to :aceman from comment #47)
> Was this actually ever landed? Or is the "disable" patch just for
> completeness if it lands prematurely?
> 
> BenB, Thomas, what do you think is still missing here?

Nothing. This bug should be closed. Worksforme, invalid, wontfix.

This has lost practical relevance as "Ask me" is no longer the default, because we found that asking users annoys confuses them more than anything, and receiving HTML messages is no longer a problem except for a few niches like traditional newsgroups.
From an UX perspective, this is a can of worms which we can NEVER get right without massive user confusion, and violating a range of UX principles.

Just try writing up a correct description for that "remember-checkbox":
"In this particular message, you have some prefers-plain, some prefers-html, and some prefers-unknown recipients. For the prefers-unknown-recipients of this message (John Doe <[e-mail]>, Jane Simpson <[e-mail]>, Miss Miller <[e-mail]>, etc. etc. etc. etc.), we'll remember that you have decided for this message to downgrade a message of type convertible::altering to plaintext. convertible::altering means that you have used the following HTML tags which we will remove from your message: *#§$%"&/() etc. etc. (list of formatting tags which we'll dump). This will distort the formatting of your message, so what you see in composition is not what will be sent. In the future, the prefers-unknown recipients of this message will be marked in AB to prefer plaintext. This will cause that if you send a message to those recipients (now remembered as prefers-plain), and there are other recipients (prefers-html), the prefers-html recipients will no longer get formatted messages, but you won't notice until they complain about poorly formatted messages. Do you understand the consequences of what you are doing and are willing to accept them?"

As a matter of fact, as mentioned in this bug, it is not reasonable to remember "prefers-plain" decisions from a formatting decision for *one* particular message which user wants to send as plaintext.
Remembering only "prefers-HTML" is safer, but also pretty useless if you need to repeat it for each and every new recipient. You'll still get asked at least once for every recipient, which is annoying and doesn't help anything.

Judging from the significant user resistance against downgrading even for cases of less significant HTML formatting (like fixed-width <tt> vs. variable width <p>), most users are certainly not interested to remember anything which downgrades their messages even more, even just for certain recipients; definitely never for all recipients because this leads the concept of wysiwyg HTML compositions ad absurdum.

Let's give the user reasonable default choices like "unknown-prefers-html" (or plain, or both), and per-identity message-centric default choice (for this identity, generally start composing messages as "auto-detect | plain (?) | html | both). Recipient-centric logics are less important these days.

You know, users have more important issues than to waste their time fine-tuning the best format for sending messages, when HTML is a universally accepted delivery format which coincidentally drives the whole world wide web...

Comment 49

[Thomas D. (:thomas8)]

^^ comment 48

Comment 51

[rsx11m]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #48)
> This has lost practical relevance as "Ask me" is no longer the default,

While that's correct for Thunderbird, it doesn't apply to SeaMonkey. By default, it's still presenting the askSendFormat dialog, thus the user could be enabled to remember a decision made once.

If that's a WONTFIX for Thunderbird, please move into SeaMonkey/MailNews:General component (though I'm not sure if it's possible for SeaMonkey to produce a solution - if so wanted - that leaves Thunderbird behavior for that box unchanged).

Comment 52

[Thomas D. (:thomas8)]

WONTFIX for THUNDERBIRD per detailed explanation in my comment 48.

In terms of UX, as explained in comment 48, this is a can of worms which is all but impossible to implement in a way that can be correctly and fully understood by the user without extensive explanation (see e.g. comment 31), which is undesirable. Otherwise it's a nightmare of UX-error-prevention. Plus the lack of per-recipient AB setting for "both" also makes this pretty useless: in case we'll keep recipient-centric logics, "both" should be added, as in my patch 8943334 in bug 1222176. That bug also presents a better alternative by allowing user to flexibly set a reasonable default format for any recipient which is not explicitly set to prefer a certain format (instead of hard-wiring each user to a certain format which you'll later regret).

This bug seeks to avoid showing the HTML format question dialogue, but by default already we're no longer showing that dialogue at all because it is too annoying and has become obsolete because HTML is no longer a problematic format for the vast majority of recipients. So there's no point to waste our time here to improve an outdated/disabled by default usecase/edge case. In fact, Magnus has proposed to remove recipient-centric format determination altogether, with the consequence of obsoleting this bug.

Moreover, this bug is in a very poor state starting from comment 0 which is incomplete and outdated, and the discussion about what has been tried and abandoned again over time speaks volumes about the non-feasibility of this idea.

However, per rsx11m's comment 51, SeaMonkey still nags users with HTML format question and might hence want to try this -> moving to SeaMonkey product.