Closed Bug 111164 Opened 23 years ago Closed 22 years ago

View of Message source should keep the character coding

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
Windows NT
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.2alpha

People

(Reporter: lizal, Assigned: bugzilla)

References

Details

(Keywords: intl, polish)

Attachments

(5 files)

The newly implemented View of Message source (View/essage soUrce) should keep
the character coding which was set for the Mail, i.e., the setting of
View/CharaCter coding, (instead of using the Western coding by default? In my
case, it uses Western instead of the selected Central european ISO.) The proper
coding is not used even if the mail header contains section
Content-Type: text/plain;
	charset="iso-8859-2"
Keywords: intl
Confirming on 2001112003, Win98, for plaint text and html messages written in
ISO8859-7 (8 bit text in body, correct mime information). Marking as NEW, adding
intl keyword.
Confirming on 2001112003 (trunk), Win98, on plain text and html messages with 8
bit body and correct mime info (ISO-8859-7). Tried on new profile, same results.
Marking as NEW, adding intl keyword.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Source of a message that isn't displayed correctly on View Message Source.
QA Contact: esther → marina
QA Contact: marina → ji
i am seeing this with 2001-11-26-03 build
reassigning to ducarroz.
Assignee: sspitzer → ducarroz
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2
Using Mozilla build 2002040814

I think my problem belongs to 111164 bug:

Original message:
A questão é que, em casos de NAT, o StoneGate permite alterar o endereço IP
de origem, quando este faça parte do _payload_ do pacote em alguns
protocolos, para o endereço de NAT. O cliente pretende saber se o FP1 também
tem essa funcionalidade.

With View Message Source:

A quest=E3o =E9 que, em casos de NAT, o StoneGate permite alterar o =
endere=E7o IP
de origem, quando este fa=E7a parte do _payload_ do pacote em alguns
protocolos, para o endere=E7o de NAT. O cliente pretende saber se o FP1 =
tamb=E9m
tem essa funcionalidade.
*** Bug 126120 has been marked as a duplicate of this bug. ***
The same problem also occurs when opening an attachment that is displayed
inline, e.g. a .pdf file. After viewing such an attachment, the display of
special characters (German Umlauts) is messed up.
QA contact to marina. Thanks.
QA Contact: ji → marina
Attached patch Proposed patchSplinter Review
I've included some cleanup in this patch:
I used try/catch because getService doesn't return null, it throws exceptions.
I removed the "?header=src" which is no longer necessary.
Depends on: 125723
I don't know who's best to review this so CCing likely suspects.
Keywords: patch, polish, review
Comment on attachment 99046 [details] [diff] [review]
Proposed patch

r/sr=bzbarsky, but please use the When In Rome rule on the whitespace here..
unless the file already has all sorts of mixed whitespace styles, of course.
Attachment #99046 - Flags: superreview+
Comment on attachment 99256 [details] [diff] [review]
Fixed whitespace

r=nhotta
Attachment #99256 - Flags: review+
checked in, marking fixed
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: