Bugzilla

Thanks Matt. I have successfully advocated for reducing the format-loss impact of this option in the past, and for having this pref exposed in the UI at all. Atm I would think it's quite acceptable as-is, and I'm not sure about defaulting to HTML overhead when there's virtually zero formatting in the message.

- What's stopping users from just unchecking the pref in the UI? Note that the `Send Options` dialog will be going away in bug 1727493, which will elevate the `[x] Send messages as plaintext if possible` checkbox to the main level of Composition prefs section, hence easier to find.
- Can you be more specific about the alleged 'formatting' which your sample users feel is getting lost? Note: We can never fully control the message display of the receiving client.
- Screenshots / testcases?
- Links to support questions?

Thanks Matt. I have successfully advocated for reducing the format-loss impact of this option in the past, and for having this pref exposed in the UI at all. Atm I would think it's quite acceptable as-is, and I'm not sure about defaulting to HTML overhead when there's virtually zero formatting in the message.

- What's stopping users from just unchecking the pref in the UI? Note that the `Send Options` dialog will be going away in bug 1727493, which will elevate the `[x] Send messages as plaintext if possible` checkbox to the main level of `Composition` prefs section, hence easier to find.
- Can you be more specific about the alleged 'formatting' which your sample users feel is getting lost? Note: We can never fully control the message display of the receiving client.
- Screenshots / testcases?
- Links to support questions?