Closed Bug 38433 Opened 25 years ago Closed 24 years ago

Recommend plaintext, if reasonable

Categories

(MailNews Core :: Composition, defect, P1)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: BenB, Assigned: BenB)

References

Details

(Whiteboard: [nsbeta2-] Fixed.)

Attachments

(12 files)

Fix, version 1: |cd mozilla/mailnews/compose; cvs diff -u .|
(deleted), patch
Details | Diff | Splinter Review
Fix, version 2
(deleted), patch
Details | Diff | Splinter Review
Fix, version 4
(deleted), patch
Details | Diff | Splinter Review
Fix, version 5
(deleted), patch
Details | Diff | Splinter Review
Fix, version 6 - Factoring out some code to reduce redundancy
(deleted), patch
Details | Diff | Splinter Review
Screenshot of current impl., case convertable
(deleted), image/png
Details
Screenshot of current impl., case not convertable
(deleted), image/png
Details
Fix, version 8
(deleted), patch
Details | Diff | Splinter Review
Fix, version 9
(deleted), patch
Details | Diff | Splinter Review
Fix, version 10, mailnews/composer
(deleted), patch
Details | Diff | Splinter Review
Fix, version 10, skin changes
(deleted), patch
Details | Diff | Splinter Review
Fix, version 10, Icons
(deleted), application/x-zip-compressed
Details
Description: We can convert several HTML tags to plain text without data loss: ul, ol, li, blockquote (without cite), b, i, u, strong, em, code, a We should suggest plain text in the askSendFormatDialog, if the msg contains only those (and <html> etc.) tags. In other cases, we should force a decision by giving no default like we did in the past im Mozilla Mailnews. Importance: This is important interop. nsbeta2 nomination. Newbies have no idea, if it will loose data and take the "save" choice to HTML (or HTML+plain text), if not necessary, which causes hostile reaction on the other end. Power users like myself know, that Mailnews can convert it and use those tags in the HTML composer, even if they intend to send plain text. They would save one click. Implementation: If I get the checkin permission then, I could do some of this, namely the checks, for M18. However, somebody else would have to give the askSentFormatDialog the ability to take a default.
I'll wait with the nsbeta2 keyword for Phil's answer. Phil, can we move this bug to M18 or is it considered a "feature"? I really want this to be in the shipping product.
It's a feature to have a list of HTML tags which force the "ask me" dialog. Assuming we have that code (in 4.x, the list was <html>, <p>, <br>, etc.) I'm willing to consider the optimization of that list as a bug.
I like the idea of automatically sending simple messages as plain text, and also of forcing a decision when the message can't be easily converted to plain text (as long as there's a "[don't] ask me again" checkbox on the dialog). I don't think that list should include <b>, etc, though, because it doesn't always look good to surround text with ** or __, and if a user makes the text bold, he or she probably expects it to come out emphasized.
Phil, bug 28420 is about Intelligent Send. This (38433) bug is not as easy as adding some tags to a list, since we don't yet have the ability to set the default of the ask dialog. In other words, this bug is about enhancing the intelligence of Intelligent Send. Would this be a "feature"? I'm asking, because I propbaly won't have time to implement it before M18. Jesse, - It does come out as emphasized in Mozilla (in most cases). - I don't know, what your concern is. Those tags (for structured phrases) *will* trigger the ask dialog, just the default choice will be plain text. You can easily override it. (It will not trigger, if there is only <body>, <p> etc., see bug 28420.)
Ben, now I see you're proposing a change to the algorithm for "intelligent send", and I guess that is a feature. We have, in the past, discussed setting the radio buttons in the Ask Me dialog differently based on contextual information (message contents, recipients, etc). Personally, I'm not in favor of doing that because I think it would be confusing to have the dialog settings and output content-type (!) change based on unpredictable (to the user) context. Just my opinion though...
Ah, so the dialog would contain something like "Mozilla can convert your message to plain text. This will make it easier for older mail programs to read your message, but your text formatting will be converted to ASCII hints (for example, <b>bold text</b> will be changed to *bold text*)." I don't buy your argument that "[i]t does come out as emphasized in Mozilla (in most cases)." It won't come out as emphasized in most HTML-readers, just Mozilla. And URLs could get screwed up by the extra _fake formatting_. By the way, should <a href="$1">$1</a> and <a href="mailto:$1">$1</a> be added to the list of things that get converted without asking? This should only be done if it is safe to assume that most mail clients that handle HTML mail also add links automatically in text/plain e-mails.
> I guess that is a feature. OK, nsbeta2 nomination. Without this "feature", my structured phrases feature (conversion of <strong>bold</strong> -> *bold* -> <strong>*bold*</strong>) is kind-of pointless, because it was my intention to reduce the number of "misguided" HTML msgs with it. > it would be confusing to have the dialog settings and output content-type (!) > change based on unpredictable (to the user) context. What, if we display altered text saying, that we only found "convertable" tags?
> so the dialog would contain something like Didn't read that. Yes, that was, what I had in mind. > And URLs could get screwed up by the extra _fake formatting_. Please explain. "<a href="foo://url">an<b>bold</b>url</a>" -> "an*bold*url <foo://url>" > By the way, should <a href="$1">$1</a> [...] This is bug 28420.
Keywords: nsbeta2
<a href="$1">$1</a> is already in the list of tag that doesn't ask user for convertion.
> "<a href="foo://url">an<b>bold</b>url</a>" -> "an*bold*url<foo://url>" ok, so you're saying that if the href doesn't match the anchor, we include both the plain-texted anchor plus the url in brackets? sounds good to me. > that we only found "convertable" tags? it's hard to be newbie-friendly if you use the word "tags"...
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [nsbeta2-]
Does this mean, if I won't fix it for M16, it won't be in final? Or will I have a chance for M18? I think, this is really important, but I *really* have next to no time currently.
If JF has to do any work, it can only be done before M16. If you do the work, it can be done after M16 if (1) you can convince mozilla.org (mitchell and whomever she designates) to take it and (2) you can convince the module owner (probably putterman) to take it.
Phil, tnx for clarification. REASSIGNing to myself. P1. M18 in optimism, that I'll get the permission :-). Putterman, what do you think?
Assignee: ducarroz → mozilla
Priority: P3 → P1
Target Milestone: --- → M18
Status: NEW → ASSIGNED
As long as this is just setting defaults it sounds reasonable. I'd take it if it gets code reviewed by the right people and we're confident it works. I wish I could do this for my code :)
Also, it depends on when. It's more likely to be taken at the beginning of M18 than on the last day.
putterman, tnx. /me relaxes :).
Target Milestone: M18 → M17
FIXED! Yeah! My P1 bug is done. I will attach patches as soon as I finished testing. ducarroz, can you then review, please?
Whiteboard: [nsbeta2-] → [nsbeta2-] Fixed.
Spent 1,5 full days finding XUL-engine bugs. *sigh* :(. At least, I found workarounds. ducarroz, thanks for using consts instead of numerical literals. Otherwise, one of the workarounds would have hurted much more. The changes to nsMsgCompose.cpp look more scary (at least to me) than they are: I just copied the tree-walking.
Keywords: review
Maybe I should not use C++-style comments in XUL files? BTW: Filed bug 44552 about finetuning the list of tags we ignore/recognize.
Attached patch Fix, version 2 (deleted) — — Splinter Review
Attached patch Fix, version 4 (deleted) — — Splinter Review
The old patch conflicted with ducarroz' latest changes. Attached new one. ducarroz, can you review, please?
Ben, I want be able to review it until next week.
Attached patch Fix, version 5 (deleted) — — Splinter Review
No, WONTFIX, WONTFIX! You should *never* vary a default setting in a dialog unless your reason for doing so is *extremely* obvious -- and the exact assortment of HTML tags which a particular message happens to contain, is not obvious at all. If you vary a default option like this, you make it very easy for a user who has learnt the contents of the dialog (and who is expecting one particular option to be the default) to accidentally select the wrong option -- e.g. pressing Down,Down,Enter to select another option, without even looking at the dialog thoroughly. Suggestions: * Make the text of the recommended option bold. * Say `(Recommended)' next to the best one for the given message. But *please* don't change the default selected option; if you do, undesirable messages will result, and the (sender) victims might never work out why it happened.
Matthew, the length of the text in the middle is different, making the two versions of the dialog visually obvious. So, only if you just hit Send, wait a second and then hit enter *blindly*, you will possibly have a problem. But that's your problem, as there might be a completely different dialog as well, e.g. "no subject". <example content="dialog_convertable"> recipients balbala can be converted blavbla pwrtu pwzrtpzwtr wzrpowrpüt. however, the look woiezr otwe r we opwrt öopt äoutwoärt oärati do you want iwetrut ? </example> <example content="dialog_convertable"> recipients balbala cannot be converted blavbla pwrtu pwzrtpzwtr do you want iwetrut ? </example>
(Note that the whitespace in the examples was significant, i.e. in the dialog is really some free space between the last 2 paragraphs in the second case.)
Not relevant. Intermediate to advanced users will be smart enough to fill out sender, subject etc, and they will be expecting the conversion dialog to appear. They know what the default will be, and they will have memorized the sequence of key-presses required to change from the default to the particular conversion setting they want for this message. So they don't need to read the dialog at all. But oops! they get it wrong, because you've shifted the default on them. Bad Mozilla! Bad!
(BTW: the second example was really |content="dialog_notconvertable"|.) If internediate to advanced users always want the same setting, they can (and most likely will) set the pref. See also bug 44494. Not even *looking* at the dialog is operator-error. All sorts of nasty things can happen then, and they know that.
That's assuming that intermediate to advanced users always want the same setting, in which case the dialog wouldn't be appearing in the first place. But this bug is about when it *does* appear, which means that the user has a good reason for altering their choice between messages. If I know what a dialog is going to say, not looking at it is *not* operator error. When Mac OS draws a native dialog, it draws the Ok and Cancel buttons before it draws any of the other controls, for precisely this reason: if you hit Enter or Escape fast enough, the rest of the dialog never needs to be drawn, because the system knows that you know what the dialog was going to say.
> That's assuming that intermediate to advanced users always want the same > setting, in which case the dialog wouldn't be appearing in the first place. So, you imaginary user uses even altering settings (and propably formatting), and never came across the second type of dialog before? > If I know what a dialog is going to say, not looking at it is *not* operator > error. Yes, and then we won't have a problem.
> So, you imaginary user uses even altering settings (and propably formatting), > and never came across the second type of dialog before? What's `the second type of dialog'? > > If I know what a dialog is going to say, not looking at it is *not* operator > > error. > > Yes, and then we won't have a problem. But we will, because the user will be assuming a default option which you have changed from under them.
> What's `the second type of dialog'? If we found elements not convertable to plaintext, say so and set no default at all. This dialog gives the user an additional guidiance, that he really needs. A newbie doesn't know what is the right thing to do. The right thing to do depends on the situation. We help him by reflecting this inthe software. Additionally, we offer a reasonable default for all users. If you just hit OK, you say "I don't know/care, I let the software choose the right option.". That's what we do. If a user acts blindly without knowing the app, that's his problem, not mine.
In case my comments are lost in the upper reaches of this bug report that no one ever reads anymore, I agree with Matthew -- it would be confusing to change the default values in the Ask Me dialog. > If a user acts blindly without knowing the app, that's his problem, not mine. I completely disagree with that. If a user acts on muscle memory about where controls are, or what their policy-based values are, and we change that, invalidating their reasonable expectations, that's our problem.
> In case my comments are lost in the upper reaches of this bug report that no > one ever reads anymore, I agree with Matthew -- it would be confusing to > change the default values in the Ask Me dialog. No, they were not at all lost. They were the reason why I added changing text in the dialog. And this text and its visibility (it is really hard to miss it, unless you don't look at all on the screen) are the reason why I reject Matthews objections. There are so many dialogs which can pop up during the send option. If a user really thinks he knows them all, he most likely already saw both versions of the askSendFormat dialog. If that is not convincing: Let's go through the keystokes the user could have remembered and see it there can actually be a problem in practice. In one case, we set a default, in the other one we don't, so I guess, the keystrokes have to be different to actually trigger accidently a wrong option.
bummer. No keystrokes at all currently (other than ENTER). Re ENTER: It doesn't work in the not-convertable case, so, either the user won't even try to hit just ENTER blindly, or it won't work.
> There are so many dialogs which can pop up during the send option. Yes, but the content of each of those dialogs is always the same, and it's reasonable for the user to expect them to be the same.
> If we found elements not convertable to plaintext, say so and set no default at > all. Setting no default at all is very bad UI. If this is even possible in XPToolkit, it is a bug. The only time when none of a set of radio buttons should be selected, is with Windows native radio buttons when two or more of them are selected simultaneously <http://msdn.microsoft.com/library/books/winguide/ch08c.htm>. (E.g. for a paragraph formatting dialog, when part of the selected text is aligned left, and part is centered.) That is obviously not the case here. If the Enter key doesn't work in a dialog, that is also a bug. > There are so many dialogs which can pop up during the send option. If a user > really thinks he knows them all, he most likely already saw both versions of > the askSendFormat dialog. No, because (as I already said) if you vary the default, she has no reasonable way of knowing which default is going to apply for any given message, so she doesn't know which `version' is going to appear. If you vary the default, assuming the user even realizes you are doing so (instead of repeatedly choosing the wrong option by mistake), you are wasting the user's time by forcing her to read the dialog every single time. Please just make the recommended option bold, and/or include the text `(recommended)' next to it. Don't change the default.
> Setting no default at all is very bad UI [...] > Please just make the recommended option bold, and/or include the text > `(recommended)' next to it. Don't change the default. Do you propose to have a default different from the recommended option, or what? (*This* would be *really* bad UI, certainly the worst option of all IMO.) There *are* two cases, we have to reflect them *anyhow*.
> Do you propose to have a default different from the recommended option, or > what? If the default happens to be different from the recommended option for that particular message, then yes. Imposing `intelligence' which changes the default option depending on the message will firstly cause user errors, and secondly interfere with the user's ability to deal with the dialog quickly.
I think the point that's been missed in all this is that we're assuming we know what's best for the user better than they do. There's the assumption that if a message *can* be converted to text, then it *should* be, regardless of what *they* know about the addressee's mail client. They may not have specified that the addressee can receive HTML e-mail, but that doesn't mean they can't. A better default, I think, would be to send plain text and HTML both, preserving the content as entered and allowing the mail client to process it normally. Generally speaking, faux machine intelligence is *good.* If we can do simple things to predict the users needs or focus of attention, that makes the product look and feel better. But that assumes that we can reliably predict their desire. If we *can't* and we predict incorrectly, then it quickly moves from good to downright annoying. This is a very simple case, but one in which we can't reliably predict how a user, beginner or advanced, is going to treat each e-mail. Better to simplify and give them a single solution which better matches their needs than a more complex one that might just confuse them. I would recommend a single dialog, always defaulting to "plaintext & HTML" where the plaintext automatically gets as much faux formatting as possible and which explains that some formatting may be discarded if "plaintext only" is selected. For example: Mozilla can convert your message to plain text. This will make it easier for older mail programs to read your message, but some text formatting may be lost. (O) Send plain text and HTML. ( ) Send HTML only. ( ) Send plain text only.
> I think the point that's been missed in all this is that we're assuming we > know what's best for the user better than they do. In many cases, we actually *do* know it better. I think, most, or at least many, users don't understand the problem fully. So, we give them a good recommondation. I argue that the fix for this bug *considerably* increases the quality of the recommondation. *But* I do not assume that we know it better in all cases. That's why the dialog still pops up. The user stilll has the same choices as before, just that we make a better recommondation now. > A better default, I think, would be to send > plain text and HTML both, preserving the content as entered and allowing > the mail client to process it normally. NO. Please refer to the discussion "Assuming "plain text" or "html mail".." on .mail-news <news://news.mozilla.org/37FA67D5.C902C699@netscape.com>. This is what 4.x did, and it caused *a lot* of complaints and problems. Many people consider sending HTML rude, even if it's a multipart msg. Plaintext Only is the safest choice. 4.x even says so in the help (but fails to implement this in the software). -- I suggest to review and checkin the patch. I argue taht it is a large improvement over the previous state. The extend of formatting is one factor in the calculation what format to send, and this fix reflects this in software. What Matthew is discussion about is IMO UI polish. If we always set the same default choice and just change the recommondation or the text, or if we change the default choice based on the recommondation, or what the default choice should be, is IMO important, but, from the coding perspective, just minor tweaks to fix I submitted. I think, setting the default based on the recommondationis the most obvious solution for now, and we have a working patch for that. So, please let us check this stuff in and file a new bug about the polish. But please be sure to have consensus or at least a majority for the solution you propose in the bug.
> just minor tweaks to fix I submitted. just minor tweaks to *the* fix I submitted. I.e. my patch contains teh bulk of teh work, and it has to be done anyway. The rest are just tweaks.
Ben, you completely skipped over the point of my argument, choosing to focus instead on a suggested example dialog. Thank you for pointing me to that particular thread in the newsgroup, however, because I now see that this is entirely a personal issue for you and has little to do with "* a lot* of complaints and problems." Back to the original point, *MOST* users don't care *what* format they're sending. MOST users just want to send their mail and be done with it. It's generally engineers thinking they know what's best for everyone that get in the way and force all these different formats on people who couldn't care less about HTML, plain text, multi-part messages, or any other under-the-hood detail. When the case arises that the user must be presented with a choice, for whatever reason, that choice should be clear, simple, and predictable. Whether or not they *should,* users do not always process every dialog that comes on screen. Indeed, many users will not even *see* them, depending on where the dialog pops up and where their attention is focused at the time. Even more important than the dialog itself, the *result* needs to be consistent and predictable. If a user sends two messages and one message gets through fine and the next does not, either because the recipient can't receive HTML *OR* because formatting was auto-magically stripped away in an effort to meet the lowest common denominator, that user will be confused, irritated, even angry. If the interface does not make clear what all the options are and why one would be chosen over the other and present that same choice every time and in the same manner, then the interface has failed. It will not help them understand what went wrong or what variables might have changed. It will not help them understand what the right choice is and why. It will not help them make a better choice next time. Creating a special case that says, in essence, "you have created a special-case e-mail which can be somewhat safely converted to a more-widely accepted format, though it may not come out looking exactly like you sent it and it may not be necessary to convert it at all" is not helpful. It complicates the matter unnecessarily and does not help the user understand why this particular special-case e-mail can be converted nor what the converted e-mail will actually look like. Therefore, I am recommending that, as Matthew and Phil have both said already, we have a single dialog, with the same default which is tuned for the best success for the majority of users. The lowest common denominator, must support every last client in the default setting approach is not useful or practical (users will rarely switch ON a feature they're not already using, but they will turn OFF features that cause conflicts). (Oh, and these recommendations are far more than just polish; they pretty much directly contradict the behavior you're advocating. UI is rarely just a surface-level issue; it involves behavior, workflow, and structure. If this is not the forum to suggest solutions to issues posted here, where exactly do you recommend I go to reach a consensus before I am permitted to suggest alternatives to your demands?)
> I now see that this is entirely a personal issue for you and has little to do > with "* a lot* of complaints and problems." NO. I fight for plaintext *only* because it caused "*a lot* of complaints and problems". Personally, structural HTML in email is fine with me. > Back to the original point, *MOST* users don't care *what* format they're > sending. MOST users just want to send their mail and be done with it. But user *do* care in which format they *recieve* msgs. The result of that is that the software of the recipient has to care. That's what I implemented (partly). > If the interface does not make > clear what all the options are and why one would be chosen over the other The interface implemented with this fix does this. > present that same choice every time that would be wrong, becauseu the right choice chanegs depending on certain variables (which we check *and* explain to the user). > I am recommending that [...] we have a single dialog, with the same default > which is tuned for the best success for the majority of users ... and thus "Plaintext Only". > where exactly do you recommend I go to reach a consensus The newsgroup n.p.m.mail-news.
Corrections: > I fight for plaintext *only* because The reason why I fight for "Plaintext Only" is that ... > the software of the recipient s/recipient/sender
>NO. I fight for plaintext *only* because it caused "*a lot* of complaints >and problems". Personally, structural HTML in email is fine with me. If you would be so kind as to provide some evidence of such. The mail-news messages contained only your opinion and no supporting evidence. >But user *do* care in which format they *recieve* msgs. >The result of that is that the software of the recipient has to care. That's >what I implemented (partly). No, it only matters that it *works.* What format it's in is irrelevant. >> If the interface does not make clear what all the options are and why >> one would be chosen over the other > The interface implemented with this fix does this. To you, perhaps, but then you have the advantage of having written it and already understanding what it does and why. You've already leapt over the part where the user has to understand what all these formats are and why they need to care. The truth is, they shouldn't need to understand or care. >> present that same choice every time >that would be wrong, becauseu the right choice chanegs depending on >certain variables (which we check *and* explain to the user). NO. That's what I've been trying to tell you: the "right" choice does NOT change because there is NO RIGHT CHOICE. You're making the assumption that because YOU want the lowest common denominator option that everyone SHOULD want the same option. That's simply not true. In fact, the large majority of users would rather not ever see this dialog or ever have to concern themselves that there are several formats of e-mail and that they are not entirely compatible (which is OUR problem, not theirs). >> I am recommending that [...] we have a single dialog, with the same >> default which is tuned for the best success for the majority of users >... and thus "Plaintext Only". Perhaps I should rephrase: the most full-featured, richest, most successful experience for the majority of users; the 90% that use mail clients that can handle HTML and/or multi-part mime. >> where exactly do you recommend I go to reach a consensus >The newsgroup n.p.m.mail-news. Ah, right. No discussion allowed here. Heaven forbid I should suggest something in a bug that I haven't first discussed thoroughly in the newsgroups. Good thinking. Better get rid of this "Additional Comments" feature, too.
> If you would be so kind as to provide some evidence of such. John? > No, it only matters that it *works.* What format it's in is irrelevant. The format is relevant for the question if it works. Some keywords: Palm, blind, preference of a mail client != big 5 (Mozilla, 2xMS, Eudora, Lotus). > the 90% that use mail > clients that can handle HTML and/or multi-part mime. And want about the rest? 10% are at least 30 millions. Shouldn't they be able to read their mail? Is there any point to send a mail the recipient cannot read? > >The newsgroup n.p.m.mail-news. > Ah, right. No discussion allowed here. Exactly, not in my bugs, not in this extend. Bugzilla is supposed to track work. I will not discuss about HTML vs. plaintext mail in this 5-line textarea. (And especially because we had this discussion already.)
[Ben said that HTML causes problems, Brendan asked for cites, Ben referred it to me] The reason that the GNKSA has a requirement that HTML not be the default, and that the program can not SET it to the default in all cases, is because when Netscape did this in an earlier version there was a rash of such post, followed immediately by a rash of objections (flames for those less polite). This goes on to this day, although most of the people "complaining" are no longer flaming, and instead are just "informing". I did a DN search for "please post html plain*" (order doesn't count) and the first 2 different subjects were request to post in plain text (to be a be a bit more precise, the first 2 non-faq subjects. The FAQ, which was for alt.html, included instructions saying that you should only post in plain text). OK, on to my own suggestion -- I'm not familiar with what is possible for prefs, but if possible I would suggest (a) setting the default to "send plain text, intelligently converted" (however that should be worded) and (b) if that is not possible, leave it set as the default radio button, BUT *disable it* so that the user has to pick one of the other options before the "OK" button is enabled. I have seen this in other programs, although I can't give you any examples off hand.
This bug won't help us pass the GNKSA, because the dialog in question only applies if the user already has `Ask Me' set in their prefs anyway. (We can pass the GNKSA if we *always* ask the user when they post a richly formatted message to a Usenet group; asking them would be eliciting `explicit user demand'.) What this bug would be doing is turning two situations into three. Before, we had: * message contains no rich formatting --> it gets converted to plain text (bug 28420) * message contains rich formatting --> ask the user, with the default as `both'. Not perfect, but relatively simple. But under the regime proposed in this bug, we would have three different possibilities: * message contains no rich formatting --> it gets converted to plain text * message contains rich formatting which is, in the opinion of Ben Bucksch, convertible to plain text without `data loss' --> ask the user, with the default as `text only' * message contains rich formatting which is, in the opinion of Ben Bucksch, not convertible to plain text without `data loss' --> ask the user, with the default as `both text and HTML'. To make things worse, the second and third situations would be presented in similar but not identical ways to the user (through a dialog which had the same options, but different defaults). The second situation should not exist. If you know what to do with the message, then just send it. If you don't know what to do, ask the user. Halfway measures like changing the default will confuse users, cause errors, and irritate people as they wonder whether the program is asking questions when it really knows the answers all along. > I did a DN search for "please post html plain*" (order doesn't count) and the > first 2 different subjects were request to post in plain text Well of course. Firstly, the search you did was of Usenet, and not of e-mail. And secondly, groups where HTML is not objected to are hardly going to feature messages saying `please post in HTML', are they. This bug needs a WONTFIX from someone. And that someone obviously isn't going to be the reporter/assignee; because one hand the one hand he is demanding that those of us who disapprove (Phil, Brendan, and myself) form a `consensus or at least a majority', while on the other hand he is recommending `to review and checkin the patch' when he doesn't have either a consensus *or* a majority.
> This bug won't help us pass the GNKSA Please note that John *made* the GNKSA evaluations in the past. > This bug needs a WONTFIX from someone. This bug was here a long time, and several people saw it, and we discussed about it *before* I implemented it. Phil expressed a concern, which I, from my POV, addressed in the implementation. After a bug is implemented is certainly a bad time to mark it WONTFIX. Is there any reason to object to change the *text* of the dialog, telling the user that we *can* convert to plaintext? The reason why we pop up the dialog might be something as easy to convert as a list or an indention, and, I think, we should tell the user so. I don't see any valid objection to change at least the text. If we should change the text, we should check this patch in and discuss the details (as listed in an earlier comment of mine) on a newsgroup.
Well, Ben Bucksch says we're not allowed to discuss this any more since it's his bug, and that since he's already fixed it, we're not allowed to do anything but throw out our own opinions and let him check in his fix. However, since it seems there is large disagreement with the fix, I'm marking this WONTFIX. From a UI perspective, it's just not a good idea.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Again: I don't see a valid objection to change the text of the dialog. REOPENing. If you want to discuss this, then - be sure to *read* the thread about plaintext vs. HTML mail (not just the headers) - discuss the details on .mailnews. Until then, please let's review it and check in the patch. It already starts bitrooting.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Status: REOPENED → ASSIGNED
I *did* read the messages. All of them. But since you're apparently unwilling to read what *I'm* saying, I'm withdrawing from this rather one-sided discussion. You just go ahead and do whatever you want.
I have to apologize to Ben. I ok'd doing this when I clearly hadn't thought through this as much as everyone else who has commented on both sides of the issue. My opinion is that we shouldn't change the default. Memory of the default is very important and if we decide that we want to make a recommendation I'd rather see it some other way such as mpt suggested. I also think the default should be plaintext and html. I'll prepare to be flamed when I write this, but although I have sympathy for those who can't receive html, if we're only alienating 10% of possible users then I don't think that's such a bad thing. (plus we are sending it in both in this situation). I don't think we should be defaulting anyone to plain text. The user made the choice to use html compose (and even if they didn't because it's the default, they made the choice to use html). This dialog is their warning that some may not be able to receive in html. So, although I don't expect my comments to necessarily stop this debate I would like to see the following things happen: 1. No changing of the default 2. Default to html and plain text 3. If we believe that users might be sending out html blindly, come up with better wording to make users understand why they are being presented with the ask me dialog.
<rant> *sigh* The old debate does start up again. And I though, we had a solution that is acceptable for all. Now, the plain text users are the loosers again. You'd think, an open source project showed a but more common sense. </rant> Reiterating: I don't see any objections to change the text and possibly add a "recommended" behind one option, without changing the default. So, if somebody has objections to that, tell them now, or I will change the patch that way, so the stuff can be checked in. The bulk of the patch is the recognition of non-convertable tags, so we should really get this in. Everything else can be discussed on .mail-news, and it requires only small changes to the code.
Not sure exactly what you're proposing Ben -- could you cite comments in the bug or newsgroup which describe your current proposal? Bdonohoe proposed this, which seems painless enough, modulo some wordsmithing: > Mozilla can convert your message to plain text. This will make it easier for > older mail programs to read your message, but some text formatting may > be lost. > > (O) Send plain text and HTML. > ( ) Send HTML only. > ( ) Send plain text only.
Phil, the current implementation recognizes that the msg only contains "convertable" (see at the very beginning for definition) elements and reflects that in the UI. It does so by 1. Adding some informational text to the dialog, which is either 1. "Your message can be converted to plaintext without loosing important information. However, the plaintext version might look different from what you saw in the composer." or 2. "However, you used formatting that cannot be converted to plaintext.", depending on the case. (We should finetune the wording later.) 2. Setting the default selection to plaintext in the first case and not setting any in the second. I will attach screenshots. My proposal is to 1. let the text part (1.) as-is, 2. add a " (recommended)" to the label of the plaintext option in case the msg is "convertable", and 3. set no default at all until we resolved this. I refuse to set the option to HTML+plaintext. I will modify the infrastructure to easily allow any of the suggestions (other than WONTFIX, of course) to be implemented. I hope we can reach consensus.
I think the current implementation is good enough, but if you think it's important to add "recommended" on text/plain in the convertable case, I don't have a strong objection to that. I do have a strong objection to having a radiogroup without a selected choice -- that's really bad UI.
> if you think it's > important to add "recommended" on text/plain in the convertable case Yes, I do think that this is important, this was the whole point of this bug. > I do have a strong objection to having a > radiogroup without a selected choice -- that's really bad UI. I agree that this is bad UI, but it is even worse to misguide the user (while it depends on the POV, what the "misguiding" option is). I don't know what to do about that. I cannot alter the default, I must set a default, we (Netscape + Matthew vs. the rest of the open source world) cannot agree on the default. I don't think, we can resolve this question here. The only question is what to do *for now* until we resolved it.
*** Bug 28735 has been marked as a duplicate of this bug. ***
I have the changes mostly ready, but are blocked by an XUL bug. I change the text using JS, and the object indeed picks up the change, but the dialog doesn't reflect it. If somebody knows a workaroung, let me know. Changing SUMMARY from "" to "" in order to reflect discussion. Will file a new bug about setting the default, if we (the Mozilla community, including Netscape) decided that that's a good idea.
Summary: Set default for askSendFormatDialog to plaintext, if reasonable → Recommend plaintext, if reasonable
*** Bug 46747 has been marked as a duplicate of this bug. ***
I have a workaround for the problem. Not pretty code, but works. I'll try to add an icon with green/yellow/red background, depending on the case. Would that change the problem of changing the default?
Attached patch Fix, version 8 (deleted) — — Splinter Review
The default doesn't change anymore (it still can, if you change one constant in the source), but a "recommended" is added behind the recommended option, if one exists. I sat the default to plaintext, but it is easily changeable. Added a new mode: Convertable without changing the look (much), e.g. only indention, <ol> etc.. If we decide so, we can skip the dialog completely in this case with only a minor code change. I had to rework most of the code to make that possible. It should be fairly flexible now. Images didn't work :-(. I'm tried of debugging XUL, so I just commented it out for now. I'll attach the images themselves later. ducarroz, please review the latest version. I want to get this in now.
good job. r=ducarroz
Keywords: review → approval
A big patch, which I can only scan for misspellings, style glitches, etc. Here they are: - Convertible is misspelled throughout. - IDL style should be interCaps, not InterCaps, for attributes and methods, and ALL_CAPS_WITH_UNDERSCORES for constants (XPIDL style matches Java style, and JS style too). The C++ bindings get capitalized to InterCaps, so there's no change required to .cpp files. - Indentation looks wrong in the patch in function Startup -- are hard tabs being used? Please expand them per the Emacs modeline comment on the first line of the file (fix that modeline if its c-basic-offset is wrong, should be 4 rather than 2 for this code, from the looks of it). - If you're not too tired, could you find out why the images don't work, or at least file a bug and cite its number in this bug? Thanks. - In the convertableAltering.label (sic), "loosing" should be "losing" -- check for other such wrong-word errors throughout. - Do I understand correctly: class="txt..." or class='"txt...' on an HTML tag is enough to identify it as coming from Mozilla compose? /be
> - Convertible is misspelled throughout. Corrected. > - IDL style should be interCaps, not InterCaps, for attributes and methods, > and ALL_CAPS_WITH_UNDERSCORES for constants (XPIDL style matches Java style, > and JS style too). The C++ bindings get capitalized to InterCaps, so there's > no change required to .cpp files. Corrected for the method I added. However, *all* methods in that interface were capitalized, I'm not going to change that. > - Indentation looks wrong in the patch in function Startup -- are hard tabs > being used? Please expand them per the Emacs modeline comment on the first > line of the file (fix that modeline if its c-basic-offset is wrong, should > be 4 rather than 2 for this code, from the looks of it). The modeline has "4". This bugged me as well, but I was unable to find out what's wrong. IIRC, I tried both spaces and tabs, but it was messed it up in both cases. > - If you're not too tired, could you find out why the images don't work, or > at least file a bug and cite its number in this bug? Thanks. Bug 49584. > - In the convertableAltering.label (sic), "loosing" should be "losing" -- Corrected. > check for other such wrong-word errors throughout. I can't, I'm not a native english speaker. > - Do I understand correctly: class="txt..." or class='"txt...' on an HTML tag > is enough to identify it as coming from Mozilla compose? d/compose I don't think, many HTML mail authors/generators will use a class (attribute) starting with "txt". (BTW: This is in an #ifdef 0)
cc brendan to a= new patch.
Attached patch Fix, version 9 (deleted) — — Splinter Review
I read the latest patch and have these suggestions: * <!ENTITY windowTitle.label "Message Format"> * <!ENTITY recipient.label "One or more of the recipients of this message are not recorded in your address book as being able to read richly formatted (HTML) mail."> * <!ENTITY convertibleYes.label "The message can be converted to plain text without any loss of information."> * <!ENTITY convertibleAltering.label "The message can be converted to plain text with only minor alterations."> * <!ENTITY convertibleNo.label "In the message you used formatting which Mozilla cannot convert to plain text."> * <!ENTITY question.label "How do you want to send the message?"> * <!ENTITY plainTextAndHtml.label "As both plain text and HTML"> * <!ENTITY plainTextOnly.label "As plain text only"> * <!ENTITY htmlOnly.label "As HTML only"> * <!ENTITY plainTextAndHtmlRecommended.label "As both plain text and HTML (recommended)"> * <!ENTITY plainTextOnlyRecommended.label "As plain text only (recommended)"> * <!ENTITY htmlOnlyRecommended.label "As HTML only (recommended)"> * <!ENTITY recommended.label "(recommended)"> (Why do you need all of those last three? Why not just the first two, or just the last one?) <!ENTITY dontSend.label "Cancel"> (Not `Don't Send', because it returns you to the message and you *can* send it later) Non-UI text corrections (meaning that you don't have to worry about them:-) ... * `Will loose data:' --> `Will lose data:' * `visual formating' --> `visual formatting' * `really affect the formatting' --> `really affects the formatting' * `recommondation' --> `recommendation' (twice) * `<!--<deck' ... Are XML comments allowed to contain < and > characters? * `<!-- Hack: box and html are workarounds for bug -->' (which bug?) * `that ask the user' --> `that asks the user' * `an anchore tag if the link is the same than the text' --> `a link if the linked text is just the link URL' * `recognite' --> `recognize' Hope this helps ...
Re images: I found another, much better way to add an image: via CSS. Works! Will attach images and patch for themes separately. (BTW: I have to change 15 (!) files to add 1 image!) Matthew, > (Why do you need all of those last three? Why not just the first two, or just > the last one?) This is part of the workaround for what seems to be an XUL bug (label doesn't switch). The first three are the real version and the last one is the workaround. > <!ENTITY dontSend.label "Cancel"> Changed. > `<!--<deck' ... Are XML comments allowed to contain < and > characters? Yes. <http://www.w3.org/TR/REC-xml#sec-comments> In comments: > * `really affect the formatting' --> `really affects the formatting' In "unified" or "context" diffs, lines starting with "-" are *removed* from the source. > * `<!-- Hack: box and html are workarounds for bug -->' (which bug?) Bug 49623. :) [other comments] Corrected or Changed
Attached patch Fix, version 10, skin changes (deleted) — — Splinter Review
Attached file Fix, version 10, Icons (deleted) —
ducarroz, can you please r= the new changes (mostly the images), please? Do I have to add new skin files to Mac project files or are the MANIFEST files enough? I can't find "macbuild" dirs in mozilla/themes.
R=ducarroz MANIFEST files are enought. Sorry for the delay, I was (and still) sick...
> R=ducarroz a=brendan? > Sorry for the delay, I was (and still) sick... np, thanks for reviewing while you're sick!
> Corrected for the method I added. However, *all* methods in that interface > were capitalized, I'm not going to change that. So if no JS yet calls any of these methods, you can safely uncapitalize all of them, because xpidl will capitalize the C++ bindings. If you're in a generous mood, go for it. You mentioned #if 0'd code -- how long do you intend any such to live? a=brendan@mozilla.org, but don't be shy about cleaning up the above. /be
Checked in! > So if no JS yet calls any of these methods Most of them are called from JS. > You mentioned #if 0'd code -- how long do you intend any such to live? I have no idea, but I have a bug about it: bug 44552. > - Indentation looks wrong in the patch I have still no idea why it looks so odd in the patch, but bonsai <http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/mailnews/compose/resources/content&command=DIFF_FRAMESET&file=askSendFormat.js&rev1=1.6&rev2=1.7&root=/cvsroot> likes my indention.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
If Netscape really wants to default to multiüart/alternative (although I don't hope it will), it just has to change |defaultElement| <http://lxr.mozilla.org/seamonkey/source/mailnews/compose/resources/content/askSendFormat.js#13>.
Target Milestone: M17 → M18
I'm posting here because my original bug report was marked as a duplicate of a duplicate of this bug. I notice that the HTML Mail Question dialog has improved to the extent that it is now completely visible. However unlike your screenshot (which was probably not Windows, in case that is relavent) it has expanded to the width of the screen, which is strange as the right half of the dialog has not content!
Neil, please grab a nightly from taday (should be online at ~10-12am PDT) and retest. Also see bug 50217. If bug still appears, please attach a screenshot.
changing qa
QA Contact: lchiang → esther
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: