Magnus, <font> is equally obsolete - https://www.w3schools.com/tags/tag_font.asp. Would you therefore like to replace the font/tt-based Mozilla editor with a modern CSS-based one in this bug (because that really **IS** what a user would expect)? That said, as a user I would expect Thunderbird **NOT** to break left, right and centre during all this poorly quality-controlled modernisation efforts. The user generally doesn't care what happens behind the scenes as long as it works. If you change <tt> to <style="font-family:monospace"> you will cause the next issue in converting to plain text: https://searchfox.org/comm-central/rev/b6b6fbded631b66339ea2e04e863cd516a47f210/mailnews/compose/src/nsMsgCompose.cpp#4983 https://searchfox.org/comm-central/rev/b6b6fbded631b66339ea2e04e863cd516a47f210/mailnews/compose/src/nsMsgCompose.cpp#4992 Would you like to cause another regression in this chain or re-write that code as well while were here? Excuse the sarcasm in this post, but I'm really disappointed how quality is (not) managed in this product: We started with bug 1625218 and bug 1622231. Then you promoted a lot of modernisation in bug 1582410 (some of which fortunately was moved to follow-up bug, see bug 1582410 comment #40 - or wasn't it?? - after a lot of my involvelment), and here we are again with the third very visible regression and instead of just returning to a simple **working** version in the **shipped** product, you're promoting more change with at least one immediate side-effect as I pointed out above :-( :-( :-(
Bug 1653545 Comment 12 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Magnus, <font> is equally obsolete - https://www.w3schools.com/tags/tag_font.asp. Would you therefore like to replace the font/tt-based Mozilla editor with a modern CSS-based one in this bug (because that really **IS** what a user would expect)? That said, as a user I would expect Thunderbird **NOT** to break left, right and centre during all this poorly quality-controlled modernisation efforts. The user generally doesn't care what happens behind the scenes as long as it works. If you change <tt> to <style="font-family:monospace"> you will cause the next issue in converting to plain text: https://searchfox.org/comm-central/rev/b6b6fbded631b66339ea2e04e863cd516a47f210/mailnews/compose/src/nsMsgCompose.cpp#4983 https://searchfox.org/comm-central/rev/b6b6fbded631b66339ea2e04e863cd516a47f210/mailnews/compose/src/nsMsgCompose.cpp#4992 Would you like to cause another regression in this chain or re-write that code as well while were here? Excuse the sarcasm in this post, but I'm really disappointed how quality is (not) managed in this product: We started with bug 1625218 and bug 1622231. Then you promoted a lot of modernisation in bug 1582410 (some of which fortunately was moved to follow-up bug, see bug 1582410 comment #40 - or wasn't it?? - after a lot of my involvelment), and here we are again with the third very visible regression, and instead of just returning to a simple **working** version in the **shipped** product, you're promoting more change with at least one immediate side-effect as I pointed out above :-( :-( :-(
Magnus, <font> is equally obsolete - https://www.w3schools.com/tags/tag_font.asp. Would you therefore like to replace the font/tt-based Mozilla editor with a modern CSS-based one in this bug (because that really **IS** what a user would expect in a modern product (Postbox has it))? That said, as a user I would expect Thunderbird **NOT** to break left, right and centre during all this poorly quality-controlled modernisation efforts. The user generally doesn't care what happens behind the scenes as long as it works. If you change <tt> to <style="font-family:monospace"> you will cause the next issue in converting to plain text: https://searchfox.org/comm-central/rev/b6b6fbded631b66339ea2e04e863cd516a47f210/mailnews/compose/src/nsMsgCompose.cpp#4983 https://searchfox.org/comm-central/rev/b6b6fbded631b66339ea2e04e863cd516a47f210/mailnews/compose/src/nsMsgCompose.cpp#4992 Would you like to cause another regression in this chain or re-write that code as well while were here? Excuse the sarcasm in this post, but I'm really disappointed how quality is (not) managed in this product: We started with bug 1625218 and bug 1622231. Then you promoted a lot of modernisation in bug 1582410 (some of which fortunately was moved to follow-up bug, see bug 1582410 comment #40 - or wasn't it?? - after a lot of my involvelment), and here we are again with the third very visible regression, and instead of just returning to a simple **working** version in the **shipped** product, you're promoting more change with at least one immediate side-effect as I pointed out above :-( :-( :-(