394725 - WYSIWYG compose: tie compose format to message delivery format (plain text vs. HTML)

Status: UNCONFIRMED

(Thunderbird :: Message Compose Window, enhancement)

Description

[Sam Garnham]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: version 2.0.0.4 (20070604)

Rationale:

Currently it is unclear whether messages will be sent in the format viewed in the compose window (e.g. HTML or plain text).

Suggestions:

1) Allow the user to specify a default selection for 'Option>Format' (e.g. the user should be able to force HTML if they like. I did hear this can be done by placing a single italic space in your signature, but this does not appear to always work, e.g. when responding to a plain text e-mail)

2) Add means to switch between viewing in each format (e.g. Option>Format should change the view as well as the output)

3) Add means to identify which format Options>Format>Autodetect will choose (e.g. change the menu item in Options>Format to bold, and provide an option on customise toolbar for a widget to show this info always on screen rather than hidden in the menus)

4) Add a blank line above and below quote parts when converting from HTML to plain text format (minor point; as the quote bar style has padding/margin above and below it, emails composed in HTML view but sent as plain text are difficult to read due to lack of spacing)

Reproducible: Always

Steps to Reproduce:
1. In 'Tools>Account Settings>Composition & Addressing' tick the 'Compose messages in HTML format'
2. In 'Tools>Options>Composition>General>Send Options>Text Format' choose 'Send the message in both plain text and HTML'
3. Compose new or reply to.
4. Check under 'Options>Format' that Autodetect is selected.
5. Check changing the setting has no effect on the compose view (e.g. text remains in variable-width font, HTML elements like tables do not get converted)
6. Check the mail in the sent folder to see which format was selected (e.g. whether the font is variable-width)
Actual Results:  
1-5. pass
6. depends on HTML elements were included. For example a 2x2 100px width table with a,b,c,d in the cells actually gets sent as:

   a
    b
c
    d

And emails with images in them with no alternate text will usually be converted to plain text and the image discarded, even if 'Attach this image to the message' is selected in 'Insert>Image'!!!

Expected Results:  
See the Details. The user should know what will be sent before he/she clicks send. It looks unprofessional when he/she has to send a follow up email apologising about their mail client and trying to send the missed/corrupted parts of their message in a different format.

Comment 1

[Thomas D. (:thomas8)]

I think the suggestions 1-4 of comment 0 are very reasonable.
We have bugs for some of them, esp. 1).
Can somebody list relevant bugs here?

I find suggestion 3) of particular interest:
- Make Format:Auto-Detect more predictable
- Find ways to inform the user *during composing* (i.e. *before sending*) which format will be chosen by Format:Auto-Detect (HTML vs. plaintext, or both).

Suggestion 2) is also interesting:
More wysiwyg when changing message format.
If user sets format:plaintext, it doesn't make sense to just continue with HTML composition as if nothing had happened, because that HTML composition will not be sent!

Comment 2

[Thomas D. (:thomas8)]

FYI - comment 0 has a nice user summary of some of the UX problems experienced around Format > Auto-Detection and other involved settings (although I think we've become a bit more preservative these days). When it comes to CSS, current behaviour of Format > Auto-Detect is still a massive dataloss violation of WYSIWYG, as I've shown with extensive illustrations on Bug 414299 (which currently has a wrong summary diluted by Ben, it's not just about <tt>, it's about general loss of formatting). For example, a full-blown HTML formatted message using CSS layout for colors and positioning (screenshot attachment 633908 [details]) gets blown up by Auto-Detect default setting and delivered as a useless, colorless, plaintext jumble (attachment 633910 [details]). Moreover, most users will not notice such dataloss because they will not usually check their sent messages unless the recipient complains (which is less likely in general and also because he might not even be aware about the formatting as composed/intended by sender).

For the big picture, see delivery-format-ux tracker Bug 889315.

Comment 3

[Thomas D. (:thomas8)]

CC'ing mkmelin and rkent, too.

(In reply to Thomas D. from comment #2)
> FYI - comment 0 has a nice user summary of some of the UX problems
> experienced around Format > Auto-Detection and other involved settings
> (although I think we've become a bit more preservative these days). When it
> comes to CSS, current behaviour of Format > Auto-Detect is still a massive
> dataloss violation of WYSIWYG, as I've shown with extensive illustrations on
> Bug 414299 (which currently has a wrong summary diluted by Ben, it's not
> just about <tt>, it's about general loss of formatting). For example, a
> full-blown HTML formatted message using CSS layout for colors and
> positioning (screenshot attachment 633908 [details]) gets blown up by
> Auto-Detect default setting and delivered as a useless, colorless, plaintext
> jumble (attachment 633910 [details]). Moreover, most users will not
> notice such dataloss because they will not usually check their sent messages
> unless the recipient complains (which is less likely in general and also
> because he might not even be aware about the formatting as composed/intended
> by sender).
> 
> For the big picture, see delivery-format-ux tracker Bug 889315.

Comment 4

[frankaen]

Confirmed. This is a terribly unpredictable behaviour in WYSIWYG.
Windows 8, x64, Thunderbird 31.6.0.
The format changes itself even in a half-word.
This should work in the simple way: if I set HTML format, a default font in HTML and so on, all the sent messages should have had enforced user's precise HTML properties.

Steps.
I set HTML format, and Palatino Linotype 12 px as the default font.
A client sends me an e-mail in txt or any other HTML formatting.
Then I reply, and if I write the answer I see it in my preferred format. However, sometimes it is sent in a completely messed up formattes, like all the message in client's format, half of that in his, half in mine. And this mess is not visible during writing.