Gene detected this in bug 1563891 and tracked it down to this regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f83f2771414cf5938a46f44e1b11cdcd5181ea0f&tochange=192e0e33eb597e8d923eb89f6d49bf42654e9d11 See bug 1563891 comment #35 STR: Compose a message to a) öö@öö.com b) jøran@blåbærsyltetøy.gulbrandsen.priv.nǿ Save draft, edit draft. a) Recipient lost b) Recipient corrupted: j�ran@bl�b�rsyltet�y.gulbrandsen.priv.n� You will notice that in case a) there is no To: header at all, in case b) we have To: jøran@blåbærsyltetøy.gulbrandsen.priv.nǿ in the message encoded in UTF-8. Gene tracked it down to a truncation that happens from a "high bit" UTF-16 character like ǿ which is U+01FF, down to U+00FF in the JS engine, so that smells like something running through an IDL-defined API of type `string`. Apparently moving some of those APIs in attachment 9169034 [details] [diff] [review] of the said bug doesn't help. I noticed that the recipients are all AString in nsIMsgCompFields.idl, so hard to tell where the information loss happens. The round trip was working in TB 68. Whilst this is not a terrible issue for TB 78.x, it's blocking further development in bug 1563891.
Bug 1658361 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Gene detected this in bug 1563891 and tracked it down to this regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f83f2771414cf5938a46f44e1b11cdcd5181ea0f&tochange=192e0e33eb597e8d923eb89f6d49bf42654e9d11 See bug 1563891 comment #35 STR: Compose a message to a) öö@öö.com b) jøran@blåbærsyltetøy.gulbrandsen.priv.nǿ Save draft, edit draft. a) Recipient lost b) Recipient corrupted: j<?>ran@bl<?>b<?>rsyltet<?>y.gulbrandsen.priv.n<?> (where <?> is the UTF-8 replacement character that BMO doesn't display) You will notice that in case a) there is no To: header at all, in case b) we have To: jøran@blåbærsyltetøy.gulbrandsen.priv.nǿ in the message encoded in UTF-8. Gene tracked it down to a truncation that happens from a "high bit" UTF-16 character like ǿ which is U+01FF, down to U+00FF in the JS engine, so that smells like something running through an IDL-defined API of type `string`. Apparently moving some of those APIs in attachment 9169034 [details] [diff] [review] of the said bug doesn't help. I noticed that the recipients are all AString in nsIMsgCompFields.idl, so hard to tell where the information loss happens. The round trip was working in TB 68. Whilst this is not a terrible issue for TB 78.x, it's blocking further development in bug 1563891.