7640 - BMW: mailto: url and encoding (can't switch unix mail encoding)

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect, P2)

Description

[bobj]

(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?

Comment 1

[Katsuhiko Momoi]

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.

Comment 2

[Katsuhiko Momoi]

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?

Comment 3

[Katsuhiko Momoi]

Assigning it to erik.

Comment 4

[Katsuhiko Momoi]

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.

Comment 5

[afalight]

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

Comment 6

[Katsuhiko Momoi]

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.

Comment 7

[Erik van der Poel]

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

Comment 8

[don]

Changing TFV to 5.0.

Comment 9

[Marek Z. Jeziorek]

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

Comment 10

[don]

Re-opening bug after Marek resovled it as remind.

Comment 11

[lchiang]

adding myself to cc: list.

Comment 12

[raym]

PSE assigned

Comment 13

[lchiang]

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.)

Comment 14

[Katsuhiko Momoi]

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.

Comment 15

[Katsuhiko Momoi]

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

Comment 16

[nhottanscp]

Accepting the bug. I think we only need a verification once mailto url is
available for 5.0 (adding [e-mail] 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).

Comment 17

[nhottanscp]

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

Comment 18

[nhottanscp]

Adding dependency to 5247 and moved to M9.

Comment 19

[nhottanscp]

Move to M10, necko has not landed so far.

Comment 20

[nhottanscp]

M11 since 5247 is M11.

Comment 21

[nhottanscp]

M15

Comment 22

[nhottanscp]

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.

Comment 23

[Katsuhiko Momoi]

** 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.

Comment 24

[Katsuhiko Momoi]

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.

Comment 25

[Katsuhiko Momoi]

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

Comment 26

[Katsuhiko Momoi]

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

Comment 27

[ji]

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.

Comment 28

[ji]

Attachment: source file for the mail sent w/o charset name in prefs.js

Comment 29

[Katsuhiko Momoi]

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.

Comment 30

[ji]

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.