(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #118092 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=118092 Imported into Bugzilla on 06/04/99 18:07) Broken out from a 3 part ESCALATION. This one is just for the Unix encoding switch bug. See http://scopus.mcom.com/bugsplat/show_bug.cgi?id=117748 When using the DS gateway, if client accept UTF-8 character, charset is automatically set to UTF-8. After a search, when you click on the mailto: url, the charset is to UTF-8 automatically in mail composition. On NT communicator crashes when assembling the mail. On WIN95 the mail is sent and arrives in UTF-7 encoding On unix you cannot change the encoding Customer (BMW) doesn't accept the workaround to change charset when the mail is received. Customer would like mail creation to be set to ISO-8859-1 after the mailto: url regardless of the charset of the page it is coming from. Or it could be automatically detected and correctly displayed as asked in bug #113344?

I looked at this with the AIX 4.1 5/15/98 build. The behavior there is that the DS Gateway encoding (UTF-8) has no effect on what the new mail composer window is: If the user has set the encoding menu to "Western" while viewing the NS Phonebook page, for example, the new composer menu shows "Western". If the user has set the encoding menu to "Japanese" while viewing the NS Phonebook page, for example, the new composer menu shows "Japanese". This seems to be different from the Windows behavior where the Gateway's encoding has an effect on the new composer window's encoding choice.

By the way, Mac 4.05-RTM has the same behavior as the Unix 4.1. So Windows is the only one behaving the way this bug describes. Before going further, can we have a consistent story across the platforms?

Assigning it to erik.

Could afalight clarify what is meant by "On unix you cannot change the encoding". This does not seem to be the behavior I've found so far.

When you are reading a mail, there is no menu available to change the encoding like on PC and MAC (under view/encoding).

Thanks. It is correct that we are lacking an encoding menu for plain text mail on Unix. There was a bug filed for this earlier. Adding dora to distribution. Hopefully she remembers what happened to the Plain Mial Window's encoding menu. This is not a problem for HTML mail since there is a functioning encoding menu in that window.

XFE is missing some of its UI. We need to assign this to an XFE engineer.

Changing TFV to 5.0.

I'm getting of all bugs to be fixed in 5.0 off the Nova radar. We'll revisit them later. --- Marek

Re-opening bug after Marek resovled it as remind.

adding myself to cc: list.

PSE assigned

Kat, I'd like to move this over to bugzilla. Can you summarize for me what the problem is that we'd have to fix/check for in 5.0? I don't want to move this directly to bugzilla since a customer's name (BMW) is mentioned. Thanks. (Also, this bug shouldn't be mcafee's since it's in mail.)

The problem seems to be two-fold. 1. We are not intializing the text body charset correctly when the underlying page is in UTF-8 and the mail composer is in plain text. (HTML mail seems to be working OK.) 2. There is no Character set menu for the plain text mail composer. These problems arise out of the Communicator 4 code base. In Communicator 5, these problems should not be there at all as we should be able to handle HTML and plain text mail via the same code. So we should either fix this bug in 4.5x, or close it out with a reminder that we should check in 5.x that this does not happen. Let me dispose of this bug when I do 4.xx review later this week. ------- Additional Comments From alecf May-25-1999 14:22 ------- Why is this assigned to me? Escalation => marek ------- Additional Comments From marek Jun-04-1999 16:02 ------- We are not going to fix it in 4.x. Ther ought to be a bug in bugzilla to deal with this.

I think this is a reminder bug for 5.0 Messenger on Unix. For now, I'm re-assigning this to nhotta.

Accepting the bug. I think we only need a verification once mailto url is available for 5.0 (adding rhp@netscape.com to cc). The current plan for a charset of a new mail (including mailto) is to use the one in the pref file (intl.character_set_name or map to mail charset in case it is not a mail charset e.g. Shift_JIS).

mailto is not yet available, marking as M8 for now.

Adding dependency to 5247 and moved to M9.

Move to M10, necko has not landed so far.

M11 since 5247 is M11.

M15

mail to url is enabled. A charset mailtourl is the same as the new mail's charset (pref's default charset or ISO-8895-1 if no pref specified). Need cross platform verificatin.

** Checked with 12/8/99 Win32 build ** The observed behvaior is as explained by nhotta with the above build. 0. I used user_pref("intl.character_set_name","iso-2022-jp"); as the test prefs.js line. 1. I used the above URL page (which is encoded in UTF-8) and clicked on the mailto link and sent out mail with some text in it. 2. I also deleted the above line and tried step 1. In case of 1, I got mail in "iso-2022-jp" -- header was mime-encoded correctly and the body was encoded in iso-2022-jp. In case of 2, I received the message in iso-8859-1. So these are expected results. The fix is verified under Win32. (There was an unrelated problem to this fix with the mailtoutl but this will be filed as a separate bug.) ji, please verify this using the same method for Linux.

Note that if there is a checkmark or some indication in the Character Set menu, we don't have to send out a message to find out if this is working but currently the menu has no feedback as to what charset it is using to send out mail. Also, Netscape internal Phonebook would be a good test case but the Phonebook search does not work well with Mozilla at present.

Over to ji for Linux verification. When you're done, mark this verified/fixed.

Apparently I forgot to paste in the test URL. I just did so. Use this one at the URL field.

With Linux 1999121508 build, in case 1, which doesn't have charset name in the prefs.js file, I sent out a mail from the above URL in plain text mode. The header is MIME-encoded correctly, but the body is encoded in us-ascii. Please see the attachment for the source of the mail.

You didn't include 8-bit characters in the body, right? In that case, US-ASCII is expected. If the body includes real 8-bit characters, you shoudl get ISO-8859-1. The header contains 8-bit characters and so bears iso-8859-1.

Yes, you are right. After i inluded 8bit chars in the body, the body is encoded in iso-8859-1 as expected. Marked as verified.