Stesp to repro: - open Account Wizard, Edit|Account setting; - enter a non-ascii name into the Replyt- field ( cyrillic name <firstname.lastname@example.org> - close Mail, reopen; //note: the non-ascii name is garbled on the Reply-to field
There is a regression bug 77967 today, is this also a regression?
After I enter some Japanese characters on Reply-to Address field, save it and go back to the same screen again, the Ja chars are saved as ASCII characters. For example, hiragana a is save as ascii "B". It happens on 04/26 build too. It doesn't look like a regression. Is that we can only be allowed to enter ascii in Reply-to Address field?
i don't think it is a regression. I remember that we could not enter "nonasciiname<email@example.com>" before.
in 2001-04-18 build the non-ascii string entered in the Reply-to field on thhe account wizard is not remembred after you close/reopen Mail, it is just lost. So in a way it is not a regression but a progress :-)
Reassign to putterman.
reassigning to racham.
Same problem with BCC antoher address field on copy and folder settings window.
ji, Is this confirmed with today's build. Lately, fix to the similar problem has been checked in. It was fixed at prefs level and that should ideally take care of these kind of problems too. Please let me know. thanks. bhuvan
can not reproduce in 2001-05-09 ; non-ascii chars are saved correctly
Just checked Mac 2001-05-10-04 mtrunk build. It has no problem with Latin-1 accented characters, but Japanese characters are garbled. And this happens both on Reply-to and BCC to other address field. I'll check win32 and linux build when testable builds are available.
with Win 2001-05-09-04 build JA chars can not be saved correctly in any field
this problem still exists in mozilla builds , charset that is non-latin1 can not be correctly saved on the Account manager. For .ex would i use a cyrillic name for the Reply-to field on english system it would be saved incorrectly. If the user doesn't know that because the name displays correctly while being typed he would not understand why he sees garbage in the composition window on the Reply-to field (and CC and Bcc). This type of mail would not be sent in current builds because the recipient is not recognized a valid.This is a serious problem, and needs to be fixed. Nominating
Created attachment 72814 [details] here is a screen shot to illustrate the account display problem (cyrillic charset is used)
Created attachment 72816 [details] here is an error you'll get in case you will send the mail with the incorrect display of the recipient name
The Reply-to field is on AccountManager's main panel. Changing the summary to reflect the same.
Discussed in Mail News bug meeting with Engineering, QA, Mktng and PjM. Decision was to plus this bug.
I'm going to minus this because if the user just types their email address in then it will work, ie <firstname.lastname@example.org> Scott
nominate for nsbeta1
The account wizard has three fields: "Account name" (this one accepts non-ascii names), "Email address" ( this one is explicitly saying that only emails are expected to be entered ) but in the third field we say :"Reply-to Address" and the user could try to enter the pretty name here like "email@example.com". This field doesn't accept pretty names , the non-ascii string enter here will be saved as gibberish. So we have a choice to either change the code (in many places) to be able to save the string in unicode (probably too late for this release) or maybe change the wording for Reply-to address to make it clear that ONLY email address (no pretty name) is going to be collected. Jennifer, what's your take on this? Cc'ing Jennifer and Scott.
>or maybe change the wording for Reply-to address to make it clear that >ONLY email address (no pretty name) is going to be collected. "Reply-to Email Address:" (sorta long) or "Reply-to Email:" (not sure about this one)?
I prefer "Reply-to Email Address:" if space allows. This is a more descriptive label than "Reply-to Email:" . Including the phrase "Email Address" is the clearest way to describe what we're asking for.
The "Reply-to Email Address" sounds good to me... one question though: do we want to permanently exclude the use of pretty name for the Reply? The "From" field is made of a combination of two strings: "Your name" and " Email address". The fact that "Your name" field accepts non-ascii chars allows us to enter a Name in japanese, chinese etc... The Reply then will only include the email address though the user could have a different Display name associated with a reply address... I am thinking how consistent is this design..?
OK, i think i understand better now. "PrettyName <firstname.lastname@example.org>" works with ascii chars but "PrettyName" gets messed up when using non-ascii characters. I would think the best solution would be to allow non-ascii characters for PrettyName.
Greg, another bug for your consideration.
Mail triage team: nsbeta1-
Comment on attachment 72816 [details] here is an error you'll get in case you will send the mail with the incorrect display of the recipient name This attachment is not useful because the error message being shown is about the lack of a To: address in the email; it's unrelated to the Reply-To problem. It is true that Unicode characters (beyond 0xFF) are stored oddly, as shown in attachment 72814 [details]. In Mozilla 1.8a6, an illegal Reply-To header is simply left off the new message; but in TB 1.0, such a header is truncated at the first illegal character -- see bug 208577.
(In reply to comment #27) > In Mozilla 1.8a6, an illegal > Reply-To header is simply left off the new message; but in TB 1.0, such a > header is truncated at the first illegal character -- see bug 208577. Being a little pedantic and pointing to comment #23 and the cone I made in bug 208577 (number 6), I would like to stress that this is not limited to illegal characters (such as those in the email address) but also to any non-ASCII character (such as those one might use when preceding the address with a PrettyName).
Created attachment 571270 [details] [diff] [review] fix
no easy way to write unit test because this is attribute.
Comment on attachment 571270 [details] [diff] [review] fix thx for the patch