This is a tracker bug for delivery format UX issues (HTML vs. Plaintext), with special focus on the interaction of {Delivery Format | Auto-Detect} with other settings and related UX-failures. There is a recurrent theme in many bugs that users are reporting problems of ux-control, ux-consistency, ux-efficiency, ux-wysiwyg, and ux-trust regarding the delivery format of their compositions, especially involving unexpected downgrading of HTML compositions to plaintext by Auto-Detect feature, which is currently the forced default for many everyday scenarios. The historically-grown interactions between the various settings and behaviours are highly complex and not transparent to the extent of being practically unpredictable. This tracker wants to provide an overview and a central easy access point to related bugs and RFE's with an intention of assisting us to analyse and find sustainable solutions for the above-mentioned ux-problems. Please add respective bugs and RFE's to the Depends On field of this bug.

I'll also add some resolved bugs which provide historical context and thus useful information for understanding and addressing the ux-problems of the status quo, e.g.: Bug 28420 - HTML Intelligent Send asks when no html formatting present. Patch attachment 8898 [details] [diff] [review] found in that bug looks like one of the spots where we start to ignore HTML tags based on the wrong assumption that they are irrelevant/unintended wrt formatting.

FTR: This bug 889315 might have partial intersections with HTML-compose-tracker bug 152942, currently having this summary: Bug 152942 - META: Tracking bug for issues with HTML mail compose (incl. reply and forward) However, they are different in scope and focus: - Bug 152942 was dormant from 2004 to now (2013), and scope/focus are not very clear - Per current summary, Bug 152942 has a much wider scope (any composition bugs involving HTML) - This bug 889315 has a much more limited scope (composition bugs involving delivery format ux), with a special focus on ux problems surrounding {Delivery Format: Auto-Detect} and other related settings.

Bug 78794 - For plaintext messages, "Edit Message as New": No way to trigger HTML format for composition (Message Compose HTML toolbar is not displayed) Bug 216132 - Toggle mail compose between plain text and html Bug 78794 provides a good example how ux-problems around {Delivery Format: Auto-Detect} badly interact with other delivery format ux issues: First, Auto-Detect aggressively downgrades HTML compositions to plaintext (stored in Sent), then bugs like Bug 78794 and Bug 216132 make users get stuck in plaintext composition regardless of their declared preferences for HTML. (In reply to Thomas D. from Bug 78794 comment #41) > ux-control: users don't feel in control because even when they set all > possible settings to prefer HTML, this bug 78794 will still occur. Worse, due to > the wrong design around Format > Auto-Detect (e.g. forced on everybody: bug > 136502; too aggressive: Bug 584363 Comment 16; dataloss: Bug 414299 Comment > 108), users who have or want nothing to do with plaintext can easily run > into this bug: First, we forcibly downgrade their HTML compositions to > plaintext without users' consent. Thus sent msg gets saved by TB as > plaintext, although originally composed as HTML. "Edit as new" on such sent > msg then forces plaintext editing with no way out (this bug), short of using > all sorts of weird workarounds. > > ux-efficiency: obviously, possible workarounds like using reply, forward, or > copy and paste into HTML composition are violating ux-efficiency to the > point of ux-interruption. > > ux-consistency: We should examine the general design currently defined by > complex interaction of various settings: per-account-HTML composition, > per-message-Format-Auto-Detect, per-address-Prefers-HTML-determination > etc... As I explained elsewhere, while all of these certainly have their > historical reasons, their interaction is no longer transparent enough, and > wrongly based on outdated assumptions about users' preference for plaintext. > There's evidence on a lot of bugs that users (even devs) have little > knowledge about those settings, much less their interaction, but users are > expecting ux-wysiwyg in a more message-centric perspective: You either have > a general preference for composing in plaintext, or you don't. For those who > don't, it comes as a surprise that while for a given plaintext msg, Reply > and Forward will open HTML composition, only "Edit as New" behaves > differently and forces plaintext (hence ux-consistency). For such users, > "Edit as New" is just another way of starting a new msg in their preferred > format (HTML). Imo that's not the same thing as using templates from > templates folder, where templates having plaintext can be assumed a > deliberate choice of format. > > ux-trust: Wrong design wrt such basic operations as composing in users' > preferred format can easily have a negative impact on users' trust of our > product.

^^

(In reply to Thomas D. from comment #3) > Bug 216132 - Toggle mail compose between plain text and html Oh, and Bug 216132 has another big twin, Bug 140800 (merge pending, see Bug 216132 Comment 65): Bug 140800 - switch for plain text/html in compose window In support of the aims of this bug 889315 as laid out in comment 0, those two bugs provide an impressive testimony how much delivery format ux matters to users (especially ux-control and ux-efficiency): Bug 140800: currently 56 votes, 39 users cc'ed, and 11 duplicates (constant inflow from 2002 to 2009). Bug 216132: currently 51 votes, 62 users cc'ed, and 12 duplicates (constant inflow from 2003 to 2012). Notwithstanding potential intersections of votes and users cc'ed, that's an impressive demand, corroborated by the constant inflow of 23 duplicates between 2002 and 2012. > Bug 78794 provides a good example how ux-problems around {Delivery Format: > Auto-Detect} badly interact with other delivery format ux issues: > First, Auto-Detect aggressively downgrades HTML compositions to plaintext > (stored in Sent), then bugs like Bug 78794 and Bug 216132 make users get > stuck in plaintext composition regardless of their declared preferences for > HTML. [...]

^^

Short of reading bug 414299 (where you'd have to read the full story to see what's really going on and what this is about, as summary and keywords have been heavily clipped by a prejudiced party), read shorter Bug 677171 for some philosophical background and to see why progress on any ux problems caused by {Delivery Format: Auto-Detect} is so hard to get against the unfounded blanket resistance of the developer who coded this with a clear preference for plaintext (which was useful at the time, but is now outdated, apart from all those ux-problems and dataloss which makes entire layouts go down the drain). If you're the visual type, take the shortcut and compare these screenshots which illustrate the format dataloss currently caused by {Delivery Format: Auto-Detect}: composition (as designed by user): attachment 633908 [details] vs. message sent (after aggressive downgrading to plaintext by {Delivery Format: Auto-Detect}): attachment 633910 [details]

^^

(In reply to Thomas D. from comment #7) > If you're the visual type, take the shortcut and compare these screenshots > which illustrate the format dataloss currently caused by {Delivery Format: > Auto-Detect}: > > composition (as designed by user): > attachment 633908 [details] > > vs. > > message sent (after aggressive downgrading to plaintext by {Delivery Format: > Auto-Detect}): > attachment 633910 [details] For these and more dataloss testcases, fully documented with screenshots, HTML source, and explanations, see bug 414299. For a tentative list of HTML attributes for which full dataloss of style attributes and other attributes will occur, see Bug 414299 Comment 108.

Reference Bug 1095629. With regard to HTML vs plain text formatting -- when a new message is created, there is an inconsistency in the subsequent process stream between [messages created by the WRITE Button + Attachments Added] VERSUS [messages initially created by the Windows Explorer SEND-TO operation]. See Bug 1095629 Comment #0 for steps to reproduce initial problem (and repeat using WRITE and add some attachments). Then skip to Bug 1095629 Comment #10 Comments in between discuss how's and why's of HTML handling, giving good advice and workarounds but without resolving the inconsistency issue.

[Tracking Requested - why for this release]:

talcid, This bug has nothing to do with bwg

I think that this https://bugzilla.mozilla.org/show_bug.cgi?id=885762 must be included as dependecy

(In reply to Massimo Fidanza from comment #14) > I think that this https://bugzilla.mozilla.org/show_bug.cgi?id=885762 must > be included as dependecy Thank you Massima, but bug 885762 is about composing in HTML and failures of the editor, so it's not related to this meta bug which is exclusively about delivery format (message format) after sending (HTML vs. Plaintext). Iow, this meta bug is about Options > Delivery Format, but even though the formatting of your messages gets spoilt while composing, I understand they'll still send in the correct message format (HTML or HTML + plaintext).