> I wanted your patch as a second patch based on mine, and also with the JS Mime changes removed, so the problem becomes evident. OK, this removes my change to jsmime.js, keeps my SMTPUTF8 changes and merges in your patch. >Here are the ranges: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f83f2771414cf5938a46f44e1b11cdcd5181ea0f&tochange=192e0e33eb597e8d923eb89f6d49bf42654e9d11 https://hg.mozilla.org/comm-central/pushloghtml?fromchange=df3dbb04dd384e4c8fd7a7e01f28bde758646bb2&tochange=019eaf0f9cf72621a436ce06b2607bc5a3532fae >I don't understand comment #35: Are you saying that the new pill code from bug 440377 also impacts on being able to enter non-ASCII characters for recipients? That would be very bad and another bug we should fix separately. That pill code is all in JS and it's highly likely that it hits an API that can't handle non-ASCII input. No idea. Never heard of a "pill" before looking at this code. So any effect it might have is just an hypothesis. >EDIT: So how do I reproduce that issue? Entering jøran@blåbærsyltetøy.gulbrandsen.priv.nǿ and saving a draft doesn't seem to expose any issue. Once you have saved the draft you then have to edit the draft or "edit as new" the saved draft. Only then do you see the bad chars. This is what I mean by "reflected" in my previous comments. I tried it again on Dec 11 daily and it works OK (reflects properly when "Write" window appears). With Dec 12 archive it reflects with "replacement chars". In both cases the address looks OK before you edit the draft. So the problem with bad chars only occurs when the "Write/Compose" window appears. Also, this really has nothing to do with the SMTPUTF8 change since that only comes in to play when the message is actually sent. So the problem occurs on any daily version since Dec 12 and on 78 releases. So really my attached diff is not needed.
Bug 1563891 Comment 38 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
> I wanted your patch as a second patch based on mine, and also with the JS Mime changes removed, so the problem becomes evident. OK, this removes my change to jsmime.js, keeps my SMTPUTF8 changes and merges in your patch. >Here are the ranges: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f83f2771414cf5938a46f44e1b11cdcd5181ea0f&tochange=192e0e33eb597e8d923eb89f6d49bf42654e9d11 https://hg.mozilla.org/comm-central/pushloghtml?fromchange=df3dbb04dd384e4c8fd7a7e01f28bde758646bb2&tochange=019eaf0f9cf72621a436ce06b2607bc5a3532fae Edit: Looking through these, other than maybe the "pill" push, I don't see anything the jumps out. But even within the "pill" push, I don't see anything about char encoding or UTF* etc. There are hundreds of mozilla changes in that one day and I mostly just looked at the summaries. >I don't understand comment #35: Are you saying that the new pill code from bug 440377 also impacts on being able to enter non-ASCII characters for recipients? That would be very bad and another bug we should fix separately. That pill code is all in JS and it's highly likely that it hits an API that can't handle non-ASCII input. No idea. Never heard of a "pill" before looking at this code. So any effect it might have is just an hypothesis. Edit: "Entering" the non-ascii recipient address is not the problem. Also, once entered it displays OK on the "thread" pane and in the "reading" pane. The problem only occurs when the address is "reflected" on the "Write" window. >EDIT: So how do I reproduce that issue? Entering jøran@blåbærsyltetøy.gulbrandsen.priv.nǿ and saving a draft doesn't seem to expose any issue. Once you have saved the draft you then have to edit the draft or "edit as new" the saved draft. Only then do you see the bad chars. This is what I mean by "reflected" in my previous comments. I tried it again on Dec 11 daily and it works OK (reflects properly when "Write" window appears). With Dec 12 archive it reflects with "replacement chars". In both cases the address looks OK before you edit the draft. So the problem with bad chars only occurs when the "Write/Compose" window appears. Also, this really has nothing to do with the SMTPUTF8 change since that only comes in to play when the message is actually sent. So the problem occurs on any daily version since Dec 12 and on 78 releases. So really my attached diff is not needed.