Closed Bug 73202 Opened 24 years ago Closed 21 years ago

News mode: charset is ignored if value isn't enclosed in quotes (mail problem too)

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 90584

People

(Reporter: zappa, Assigned: sspitzer)

Details

when used to browse news shows subjects and sender in Latin1, ignoring charset (in my case set to koi8-r) the message itself is displayed properly and mail headers showed are displayed according to charset No such behaviour in mail mode
having took some more look at offending letters and news found following: regardless of the mode (mail or news) charset is ignored if value isn't enclosed in quotes (") i agree, that this is a bug of those clients and servers that stamp charset if workaround for situation may not be built disregard this bug
QA Contact: esther → momoi
Summary: while in news mode showes subject and sender ignoring charset → while in news mode charset is ignored if value isn't enclosed in
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: while in news mode charset is ignored if value isn't enclosed in → News mode: charset is ignored if value isn't enclosed in quotes
I am having the opposite problem (thunderbird, 05-28 build): When the charset is in quotes, it is ignored: ------_=_NextPart_000_01C3250E.F5D47FE0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable If I use "Edit as NEw" and just Save the message to Drafts, then the message displays correctly with new charset. --------------060402080307070206060604 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit The other possibility is that it's a problem with "quoted-printable", but it's unlikely since manually adjusting the charset in "view" menu works.
I don't have the above problem with mozilla 1.4rc1. However, with "thunderbird" I do. One interesting thing: a new "Central European (ISO-8859-2)" menu item is created in the Character Set menu. The new one doesn't work, but the old one does (I didn't notice this before 'cause I had a long menu there).
Summary: News mode: charset is ignored if value isn't enclosed in quotes → News mode: charset is ignored if value isn't enclosed in quotes (mail problem too)
I'm not sure what this bug is about. Is it about the message __body__ not rendered according to MIME charset specified in 'Content-Type: text/plain; charset=xyz'? Or, is it about the raw 8bit message header [1] (in the message list display pane) not rendered according to MIME charset specified in C-T? If it's the latter, this is a dupe of bug 90584. If it's the former, can you still reproduce this bug in recent builds? Also, check your folder default charset setting to make sure that it's NOT set to override the C-T header value of individual messages
Looks like the original report is about reading news articles via a web page service. The news article probably was not displayed properly. This would be up to that web-newsgroup service and there's nothing we can do about it on the browser side. (dejanews is no more but you can try http://groups.google.com/. Comment #3 and comment #4 seem to be about Mail, but needs to be re-checked with a current build.
As comment to #5: Yes. Though it was not very clear, but the problem I meant was about incorrect rendering of raw 8bit headers. And yes, bug 90584 states it all, with standart incompatibility and etc.
resolving as a dupe of bug 90584 per comment #7 *** This bug has been marked as a duplicate of 90584 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.