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)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.2alpha
People
(Reporter: lizal, Assigned: bugzilla)
References
Details
(Keywords: intl, polish)
Attachments
(5 files)
1002 bytes,
text/plain
|
Details | |
476.30 KB,
image/jpeg
|
Details | |
544.11 KB,
image/jpeg
|
Details | |
2.41 KB,
patch
|
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
2.47 KB,
patch
|
nhottanscp
:
review+
|
Details | Diff | Splinter Review |
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"
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.
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2
Comment 6•22 years ago
|
||
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. ***
Comment 8•22 years ago
|
||
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.
Comment 9•22 years ago
|
||
Comment 10•22 years ago
|
||
Comment 12•22 years ago
|
||
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.
Comment 13•22 years ago
|
||
I don't know who's best to review this so CCing likely suspects.
Comment 14•22 years ago
|
||
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 15•22 years ago
|
||
Comment 16•22 years ago
|
||
Comment on attachment 99256 [details] [diff] [review] Fixed whitespace r=nhotta
Attachment #99256 -
Flags: review+
Comment 17•22 years ago
|
||
checked in, marking fixed
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•