Closed Bug 674184 Opened 13 years ago Closed 9 years ago

HTML Emails sent as Plain Text when no in-message styling

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Platform:
All
Other
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 584313

People

(Reporter: miscellaneous, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110615151330

Steps to reproduce:

If i create an HTML message which is styled by classes in its html <head> section but which has no styling within the <body>, thunderbird sends it as plain text even though it is configured to send as html, which is extremely irritating, since each message i am forced to put a blank space in and make that blank space bold in order for it to be sent HTML properly, and i often forget to do this.
What TB needs to do is detect a <style> element with content in the HTML and so then ensure the message is not sent as plain text...

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
Could you provide an example of your "use case" as an eml attachment please.
While strictly speaking CSS is not HTML, I tend to agree that we should look for a style tag and base the send format decision on that.
(It's pretty hard for me to imagine a composition not having at least one html tag like font-face and consisting of pure CSS.)

Not sure about 3.1.11, but with newer versions, you can over-ride the auto-detect process by using Options>>Format>>and choosing HTML.
That would save you adding an unwanted tag to the composition.
Dup of one of Bug 136502, Bug 396395, Bug 414299. Read thru these bugs for a workaround(e.g. <b></b> etc. in html signature), please.
(In reply to Joe Sabash from comment #1)
> Could you provide an example of your "use case" as an eml attachment please.
> While strictly speaking CSS is not HTML, I tend to agree that we should look
> for a style tag and base the send format decision on that.

+1. If there is styles of any sort, user rightly expects Format: Auto-Detect to detect that and send as HTML, to preserve these styles. Currently, Format: Auto-Detect will lose a lot of legitimate inline styles and other attributes, as explained in bug 414299, comment 108.

> (It's pretty hard for me to imagine a composition not having at least one
> html tag like font-face and consisting of pure CSS.)

Hard to imagine or not, it's legitimate and correct HTML with CSS, and should be preserved as displayed in our composition window (following ux-principles of ux-consistency and wysiwyg).

> Not sure about 3.1.11, but with newer versions, you can over-ride the
> auto-detect process by using Options>>Format>>and choosing HTML.
> That would save you adding an unwanted tag to the composition.

That's too easy to forget, error-prone, violating ux-error-prevention and  ux-efficiency. The very purpose of Format:Auto-Detect is to take that decision on behalf of the user, based on the content found in composition. That decision obviously needs to be "conservative" in the sense of avoiding dataloss and preserving user's formatting.

(In reply to WADA from comment #2)
> Dup of one of Bug 136502, Bug 396395, Bug 414299. Read thru these bugs for a
> workaround(e.g. <b></b> etc. in html signature), please.

We don't have a separate bug for "Format:Auto-detect removes styles and other HTML attributes" yet, so at this time, this is a duplicate of bug 414299, where this is being discussed and testcases for this wrong behaviour have been provided (see bug 414299, TC2, attachment 633907 [details] and following).
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
This is not a DUP. The other bug is about <tt> and friends, not about styles. This is a different case. I have no objections in principle here.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Summary: HTML Emails sent as Plain Text when no in-message styling → Options > Delivery Format > Auto-Detect: HTML Emails sent as Plain Text when no in-message styling; formatting dataloss of styles in <head> section
Summary: Options > Delivery Format > Auto-Detect: HTML Emails sent as Plain Text when no in-message styling; formatting dataloss of styles in <head> section → HTML Emails sent as Plain Text when no in-message styling
Ben, you removed my changes to this bug's summary.

Options | Delivery Format | Auto-Detect is a necessary precondition for this bug, so it's essential for understanding the bug, for successful bug searches, and for avoiding further duplicates, to have those terms in the bug summary.

Furthermore, the current summary does not adequately describe the main problem of this bug, which is that user-defined styles in <head> section (and potentially elsewhere) are silently removed upon sending because auto-detect algorithm does not see them yet and hence inappropriately downconverts to plaintext, which is dataloss of formatting. We need to improve our design to avoid such dataloss for users with default settings. Notwithstanding better alternatives for the wording I suggested, having clear and explicit summaries is essential for efficient bug management.

Can you explain what was wrong with the more informative summary I suggested, so that you removed it without comment?
I see an issue that might be the same. Thunderbird is configured to send mails in plain text and html. When I write a mail and do not use any formating the mail gets send as text/plain only, even when the reciepiet is configured to prefer html mails. When the mail is send as plain/test it looks different on the reciever side thus I would like it to be send in html, as set as the prefered for the recipient. I can of course force it by manually chaning the delivery options in the mail composition but it still looks wrong to me.

User Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0
Build ID: 20130913150425
Hendrik, could you please file a new bug about that? Once you did, please mention the bug number here.
Sure, I opened bug 921836.
See Also: → 414299
No longer blocks: 584313
Depends on: 584313
It looks Bug 584313 is better for processing CSS Style case.
No longer blocks: 414299
Bug 584313 is better for processing CSS Style case, so closing as dup.
No longer blocks: delivery-format-ux
Status: REOPENED → RESOLVED
Closed: 12 years ago → 9 years ago
No longer depends on: 584313
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.