232867 - view source assumes the character encoding is ISO-8859-1

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[Jungshik Shin]

The message source view window in Thunderbird assumes that messages are in
ISO-8859-1 so that non-Latin1 messages are garbled in the message source view.
It doesn't have View | Character Coding menu so that it's impossible to fix it
manually, either. Mozilla-mail has View menu with 'Character Coding' and it
doesn't assume messages are in ISO-8859-1. Firebird has 'View menu' with
'Character coding' as well. I guess it's a rather easy fix. I'll look into this
later.

Comment 1

[Robert Accettura [:raccettura]]

Looks like the menu is there now, no?

Comment 2

[Jungshik Shin]

mscott's recent change (in TB view-source) may have fixed this bug. I haven't
tried it yet.

 

Comment 3

[Robert Accettura [:raccettura]]

That's why I bring it up.

Comment 4

[Jungshik Shin]

'View | Character Encoding' menu is now included (so that I can fix it manually
in 'view-source' window), but the window is still opened up with 'ISO-8859-1' as
'documentCharset' instead of the charset of the current message for which the
source-view is requested. 

Comment 5

[Jungshik Shin]

I added 'dump' statement to print out the charset when opening up a new window
for the message source. It's correctly set, but the window still comes up with
ISO-8859-1. Mozilla uses exactly the same code and I'm wondering if there's a
rregression in window.openDialog() in recent nightlies. 

 http://lxr.mozilla.org/mozilla/source/mail/base/content/mailCommands.js#433

Comment 6

[Jungshik Shin]

Actually, Mozilla-mail has the same problem. However, the symptom is very
confusing. Before 'view-source' window is launched, 'message' is 'retrieved'
from nsMsgDB, which may account for a bit hard-to-predict/reproduce result. 

Comment 7

[Mike Cowperthwaite]

What I'm seeing currently (1.0+0414) is that if the View Source window is using 
a charset other than ISO-8859-1 or UTF-8 when it opens, that charset is not 
selected in the menu; but a useable charset seems to be in use for most 
messages.

Comment 8

[Mike Cowperthwaite]

Jungshik, this pretty much seems to be WFM for me since 1.0.  Whatever charset is in use while displaying the message is used in the Source window.  I see two problems (other than bug 350693 still being outstanding):

1) If the encoding is not part of the "list" -- that is, those set via 
  View|Encoding|Customize List  -- the encoding that gets used is not added to the dynamic part of the Encoding menu, so you can't tell what the encoding is.
(This is what I mentioned in comment 7).

2) Some messages have the encoding in the <meta> tag of the HTML part instead of the Content-Type header; these are displayed with the correct encoding within the HTML portion, but the Encoding menu still reads whatever is in the Content-Type (or whatever the folder's default encoding is).  In my case, this is often ISO-8859-1.  Again, that encoding is what gets passed to the View Source window.

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #8)
> Jungshik, this pretty much seems to be WFM for me since 1.0.  Whatever charset
> is in use while displaying the message is used in the Source window.

Resolving WFM per comment #8.

Comment 10

[Gingerbread Man]

Attachment: viewsource_utf8_garbled.png

(In reply to Mike Cowperthwaite from comment #7)
> What I'm seeing currently (1.0+0414) is that if the View Source window is
> using a charset other than ISO-8859-1 or UTF-8 when it opens, that charset
> is not selected in the menu; but a useable charset seems to be in use for
> most messages.

I'm definitely seeing garbled output here in the latest Daily with a fresh
profile. A bit more of an issue now, since UTF-8 is the default encoding
for composing new messages.

I'm not clear on the part about "most messages". Even if the source of only
some messages is garbled, that's still a flaw.

Comment 11

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Please file a new bug instead of reopening a 5 year old issue.

Comment 12

[Gingerbread Man]

I don't understand why you want me to duplicate an existing report, but okay.
Bug 1017768.