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)
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:.
Assignee | ||
Comment 1•24 years ago
|
||
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.
Reporter | ||
Comment 2•24 years ago
|
||
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.
Assignee | ||
Comment 3•24 years ago
|
||
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.
Reporter | ||
Comment 4•24 years ago
|
||
Agreed.
Resolving as WONTFIX.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Comment 5•24 years ago
|
||
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
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•