Closed Bug 57747 Opened 24 years ago Closed 24 years ago

Character coding not inherited from Browser in mailto: message.

Categories

(MailNews Core :: Internationalization, defect, P3)

PowerPC
Mac System 9.x
defect

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: tarahim, Assigned: nhottanscp)

Details

This may be related to bug 53634, and might be a regression of something. To reproduce:You have only iso-8859-1 as a default coding in Prefernces. Goto a Japanese site with Autodetect ON. Your browser will switch to Japanese charset. Then click mailto: tag in that page. Message compose window does not show any character codings in the title bar, meaning it is in ISO-8859-1. The most of users will find this irritating. The message composition should inherit the charset from the browser window when opened from mailto:.
This is an expected behavior (default send charset is used). The spec is here, http://www.mozilla.org/projects/intl/mail-news-i18n-spec.html The assumption was that the user may view messages in multiple languages but likely to stick to one language for composing messages.
Then you should either change the spec, or display the default coding in the compose window. The assumption that "user may view messages in multiple languages but likely to stick to one language for composing" sounds very Anglocentric attitude. That is not the way most of the world works.
We do not show a charset in window title in case of default charset. Please file a separate bug if you think we should show the charset anytime, this is a generic issue for mail compose. I do not think the current behavior is bad. The user can change a charset to something else. I think this is something like keyboard synchronization. Some people like it but some people don't (e.g. I don't want input method to be switched automatically). Inheriting browser charset has issues. For Japanese, we do not want to send message as Shift_JIS or EUC-JP. Those cases, we might be able to map to ISO-2022-JP. But something like UTF-8, most of the user do not want to send a message as UTF-8. For example, Netscape servers use UTF-8 pages as UI and we got customer escalation about mailto: inherits browser's charset in 4.x.
Agreed. Resolving as WONTFIX.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
I'm going to verify this resolution. One additional comment I have is that the mailto URL specification is pretty much a matter of convenience to the user while something like "form" submission is something that the server side wants to control. Thus the logic of the mailto should be left to the user's choice while the form charset is something the server side should designate. Mozilla behaves correctly in this regard. There is a way for the web page designer to specify the mailto charset, and that problem/RFE is discussed in the following bug: http://bugzilla.mozilla.org/show_bug.cgi?id=12851 I'll mark the resolution as verified.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.