User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20180103231032 Steps to reproduce: I received an EPP code (which is a string of random characters) and it included a ^ sign followed by a number. Actual results: After trying that EPP code and seeing it was refused, I noticed Thunderbird actually auto-converts ^ followed by, say number 3, to the actual exponent3 [³] corrupting the code I was expecting to receive. Expected results: Why is Thunderbird doing this? It's super annoying. If somebody sends me ^3 I expect to see ^3 not ³.
This is intentional. TB converts some plaintext content to formatting, like *bold*, _underline_ and superscripts. That's been established behaviour for a long time, so it would he hard to change that now. However, maybe in a long text string the ^ shouldn't be converted, so abc^3def should be left alone. What was the string? I closed bug 1356194 as invalid, but perhaps there should be a preference. Sadly the code that does this is in Mozilla-core, https://dxr.mozilla.org/mozilla-central/rev/64f82460345884dd0f5935645765acccf771d7c4/netwerk/streamconv/converters/mozTXTToHTMLConv.cpp#940
See Also: → bug 1356194
Well, an EPP code could look like this: X5*M6@R5^3/65JDX What happened is the ^3 appeared like this when I tried to copy/paste that code into the app: X5*M6@R5³/65JDX So obviously that led to an error until I found out that by looking at the email source, it was really: X5*M6@R5^3/65JDX I think this should be mitigated with a solution like: If ^NUMBER preceeds or succeeds a SPACE character, then apply the formatting but if there's an alpha character (letter) collapsed with it, then don't apply the formatting and leave it as is. Makes sense?
You need to log in before you can comment on or make changes to this bug.