Closed Bug 855329 Opened 12 years ago Closed 11 years ago

Incorrect view of e-mail when two (identical) charset specified

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(seamonkey2.16 affected, seamonkey2.19 affected)

Status:
VERIFIED WORKSFORME
Tracking Flags:
Tracking Status
seamonkey2.16 --- affected
seamonkey2.19 --- affected

People

(Reporter: disputant, Unassigned)

References

Details

(Whiteboard: dupeme?)

Attachments

(1 file)

This is example of such e-mail (in russian)
93.39 KB, message/rfc822
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.2 Build ID: 20130310201055 Steps to reproduce: When I view message in SeaMonkey Mail program. If mail contains two charset lines, incorrect chars viewed. When using? for example, Reply button, in compose window all chars are OK. Change encoding manually does not help. See discussion (in russian): http://forum.mozilla-russia.org/viewtopic.php?pid=607024 Actual results: Incorrecr chars (as incorrect charset was used). See https://docs.google.com/file/d/0B4DL1cHu0gJjeTRrUmxkZjR4ZlU/edit?usp=sharing Expected results: Correct russian chars...
Another dupe for bug 594646?
Whiteboard: dupeme?
(In reply to Phoenix from comment #1) > Another dupe for bug 594646? Maybe. Harry: try using "View → Message Body As → Simple HTML" on the problematic messages. Not perfect but better than nothing. You can still use "Original HTML" on message which don't show this problem. Please tell us if it works.
Attachment #730195 - Attachment mime type: application/octet-stream → message/rfc822
In this case the <meta> tag has http-equiv= before content= but the </head> closing tag and the <body> opening tag come too early: they are followed by a number of metadata items (<title>, <meta>, possibly even <style>) which ought to be inside the <head> element. So after examining the testcase source I think this is actually not a dupe of bug 594646. I can reproduce the error when viewing the attachment as message/rfc822 in the following build of SeaMonkey 2.19a1 for Linux64: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19a1 ID:20130327003001 c-c:1f5700c1bd18 m-c:178a4a770bb1
Status: UNCONFIRMED → NEW
status-seamonkey2.16: --- → affected
status-seamonkey2.19: --- → affected
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86_64 → All
Version: SeaMonkey 2.16 Branch → Trunk
Yes, it works (sorry, I wrote about this workaround in mentioned discussion, but not in bug description). Indeed, better than nothing... But this is method applied to all letters, so, better workaround is to press Reply button and read message in its own window.
See Also: → 594646
Harry: Bug 594646 was FIXED in May. I think there is a chance that it fixed this problem too (but only on Thunderbird 24 and later, SeaMonkey 2.21 and later). The current "stable" version of SeaMonkey is now 2.23, which ought to have the fix. Can you please retest?
Flags: needinfo?(disputant)
Yes, now all OK. Sorry, I don't know, what I have to do to mark problem as fixed.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(disputant)
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
Duplicate https://bugzilla.mozilla.org/show_bug.cgi?id=858982 verified works OK since Seamonkey 2.22 (maybe 2.21 as well - do not remember for sure)
It isn't INVALID since this was a real bug at the time when it was filed. It might or might not be a DUPLICATE of bug 594646. In any case it works now, so WORKSFORME looks like an adequate Resolution (OTOH, "FIXED" would mean that we know exactly which change fixed it).
Resolution: INVALID → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: