Closed Bug 505072 Opened 15 years ago Closed 15 years ago

If <meta ... content="text/html; charset=GB2312"> exists in HTML mail source, HTML mail of Content-Type:text/html;charset=UTF-8(HTML data is encoded in UTF-8, probably converted) is displayed using GB2312

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Thunderbird 3.1a1

People

(Reporter: ZaneUJi, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: intl)

Attachments

(8 files, 1 obsolete file)

nod32.eml
5.43 KB, message/rfc822
Details
Opened in mail
67.07 KB, image/png
Details
Opened in browser
56.05 KB, image/png
Details
Same data as nod32.eml (to specify charset=UTF-8 in MIME type)
5.43 KB, message/rfc822; charset=UTF-8
Details
Screenshot of header followed by Chinese text with U+FFFD
54.76 KB, image/png
Details
mail not redisplayed in UTF8 properly
81.68 KB, image/png
Details
Same data as nod32.eml (MIME : text/html; charset=GB2312 is set)
5.43 KB, text/html; charset=GB2312
Details
Fixed a regression & character set menu not working problem in mailnews
3.92 KB, patch
Bienvenu
: review+
Bienvenu
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090718 SeaMonkey/2.1a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090718 SeaMonkey/2.1a1pre

SeaMonkey mail use the encoding specified in mail header to display HTML body regardless its encoding.

Reproducible: Always

Steps to Reproduce:
1. Save the attachment as nod32.eml
2. Open SeaMonkey Mail
3. From File menu, select "Open File..."
4. Select nod32.eml
Actual Results:  
No matter which encoding is selected. the message can't be displayed correctly.

Expected Results:  
Open nod32.eml in SeaMonkey Browser, I can see what the content is.

Version 2.0b1pre (build id: 20090702001417) doesn't have such problem.
Attached file nod32.eml — 

    
    

    
  

      
      
      
      

        Attached image
          
        Opened in mail
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached image
          
        Opened in browser
        — 
      

    


  

    
    

    
  
> Content-Type: text/html; charset="utf-8"
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml">
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=gb2312" />

DUP of Bug 378008

> Version 2.0b1pre (build id: 20090702001417) doesn't have such problem.

Bug 378008 is already fixed by ignoring charset in Content-Type MIME header in text/html part processing?
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE

    
    

    
  
Reopening, because this bug is opposite problem to bug 378008.
This bug: charset of Content-Type: header is not used in process of text/html.

> This bug:  
>   Content-Type: text/html; charset="utf-8"
>  (snip)
>   <meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
>   HTML source is written in UTF-8
> Bug 378008:
>   Content-Type: text/html; charset="windows-1251"
>  (snip)
>   <meta http-equiv="Content-Type" content="text/html; charset=koi8-r" />
>   HTML source is written in koi8-r

Comment #0 says next. When regressed? Spec or implementation is changed?
> Version 2.0b1pre (build id: 20090702001417) doesn't have such problem.
> This bug is reported for Gecko/20090718 SeaMonkey/2.1a1pre
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

        Attachment #389343 -
        Attachment mime type: text/html → message/rfc822

    
    

    
  
FYI.
Mail of Bug 378008 is usually generated by mailer's bug or misuse(incorrect setup). Mail of this bug is possibly generated by archiver like software. I could see some pages which reports issue of "upon character code change, charset in meta tag is not changed" by Google search for "html mail meta charset".

    
    

    
  
Oh, this bug was for "locally saved .eml file" and "open of local .eml file by SeaMonkey".

Unable to see problem with any SeaMonkey, with Auto-detect=On or Off, with .eml file attached to this bug.
Unable to see problem with any SeaMonkey, with Auto-detect=Universal, with locally saved .eml file.
Able to see phenomenon with any SeaMonkey, with Auto-detect=Off, with locally saved .eml file.

Can you reproduce problem with .eml attachment of this bug? (Link click of attachment)
Can you reproduce problem with local .eml file, with View/Auto Detect=Enabled?
Did you use different profile for SeaMonkey/2.0bXpre SeaMonkey/2.1aXpre?
Can you see problem with real mail in mail folder? .eml file only, isn't it?

        Attachment #389859 -
        Attachment mime type: text/plain → message/rfc822; charset=UTF-8

    
    

    
  
(Correction of test result in comment #8)
"Link of attached eml to this bug" case is affected by charset parameter in Content-Type: header of HTTP. B.M.O doesn't automatically set charset=utf-8 in HTTP Content-Type: header for message/rfc822. It seems for text/html only. 
Please ignore test result about "attached eml to this bug" case in comment #8.

(Rough check result. Different profile is used by Sm 1 and Sm 2.)
                          eml attachment to this bug
                              Content-Type: message/rfc822
                              (No charset parameter)   
                          Used Character Encoding 
  Sm 1        : Off         GB2312 (default character encoding=Shift_JIS is set)
              : Universal   UTF-8
  Sm 2(1.9.1) : Off         ISO-8859-1 (my "default character encoding" choice)
              : Universal   UTF-8   
  Sm 2(1.9.2) : Off         ISO-8859-1 (my "default character encoding" choice)
              : Universal   UTF-8
Same result was obtained for locally saved .eml file with Sm 2. Not checked with Sm 1, because my Sm 1 tries to open .eml file by Tb. 

Sm 1 apparently uses charset in <meta> of HTML source in mail body when Auto-detect=Off.
Sm 2's parser of message/rfc822 doesn't look into MIME Content-Type: header nor <meta ... charset=...> in message/rfc822 data and .eml file?
Or fall back to default character encoding is executed due to "too many wrong characters for GB2312 because of UTF-8 data"?
If MIME type of eml attachment of this bug is changed to "message/rfc822; charset=UTF-8", any Sm displays the eml in UTF-8 even with Auto-detect=Off.

Note:
For Gecko 1.9.2, I checked with next build only.
> Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.2a1pre)
> Gecko/20090720 SeaMonkey/2.1a1pre
And I couldn't observe next phenomenon in comment #0.
> Actual Results:  
> No matter which encoding is selected. the message can't be displayed correctly.

    
  
Version: unspecified → Trunk

    
    

    
  
(In reply to comment #8)
> Oh, this bug was for "locally saved .eml file" and "open of local .eml file by
> SeaMonkey".
Not exactly. At first, I found one of my email can't be displayed properly. So I saved it as file so that everybody can see what the content is.

(In reply to comment #10)
> And I couldn't observe next phenomenon in comment #0.
> > Actual Results:  
> > No matter which encoding is selected. the message can't be displayed correctly.
Only happens when I open it in mail. You won't see that if you open it in browser by double clicking it. Browser works just fine. It's a problem with Sm Mail.

    
    

    
  
(In reply to comment #8)
> Can you reproduce problem with local .eml file, with View/Auto Detect=Enabled?
Even after I set Auto Detect to simplified Chinese, the result is the same.
When that .eml file is opened, email header will be displayed the first time I change Auto Detect setting. Subsequent changes have no effect.

> Did you use different profile for SeaMonkey/2.0bXpre SeaMonkey/2.1aXpre?
I've got one profile. Different versions of SeaMonkey are installed one over the other.
The difference between 2.0b1pre and 2.1a1pre is that 2.0b1pre detects the format correctly the first time email is opened. When I change Auto Detect, both versions have identical result. None of them works.

> Can you see problem with real mail in mail folder? .eml file only, isn't it?
Real mail too.

    
    

    
  
> Real mail too.

> Even after I set Auto Detect to simplified Chinese, the result is the same.
> When that .eml file is opened, email header will be displayed the first time
> I change Auto Detect setting. Subsequent changes have no effect.

I could see "header display followed by Chinese text with some U+FFFD"(probably in GB2312) with mail in mail folder(2.1a1pre is used) by; 
 a. At View/Character Encoding/Auto Detect, change from Universal to Off
    while the mail is displayed in UTF-8
 b. At View/Character Encoding/Auto Detect, change from Off to Simplified Chinese
    while the mail is displayed in UTF-8
 c. In any case, mail is re-displayed in UTF-8 properly by one of next;
    - Click of UTF-8 at View/Character Encoding,
    - Go other folder, return to the folder, display the mail

Do you add UTF-8 to list via View/Character Encoding/Customize? 
  
By the way, I saw another problem around View/Character Encoding setting.
  - Character encoding list in View/Character Encoding is not updated
    by change(add/remove) at View/Character Encoding/Customize
    until restart of Seamonkey 2.
I couldn't reproduce it after restart of Seamonkey 2.

    
    

    
  


  
This display can be obtained by next only.
  While mail is displayed in UTF-8 and Auto-Detect=Off,
  click (Off) at View/Character/Encoding/Auto Detect where (off) is selected.

    
    

    
  
(In reply to comment #13)
> I could see "header display followed by Chinese text with some U+FFFD"(probably
> in GB2312) with mail in mail folder(2.1a1pre is used) by; 
>  a. At View/Character Encoding/Auto Detect, change from Universal to Off
>     while the mail is displayed in UTF-8
>  b. At View/Character Encoding/Auto Detect, change from Off to Simplified
> Chinese
>     while the mail is displayed in UTF-8
>  c. In any case, mail is re-displayed in UTF-8 properly by one of next;
>     - Click of UTF-8 at View/Character Encoding,
>     - Go other folder, return to the folder, display the mail

Version 2.0b1pre works exactly the same way as you said. Yet version 2.1a1pre just refuse to follow that.
Just pure curiosity, how did you import that .eml file as real mail? I can't find the magic door.
> 
> Do you add UTF-8 to list via View/Character Encoding/Customize? 
It's in the list but I don't recall using Customize menu. I used to believe that encoding list menu works like that of Browse, new encoding will be added automatically when I first select it from "More Encodings" menu. And quite a few times I found I was wrong, but I didn't know why. Now you shed light on that.
> 
> By the way, I saw another problem around View/Character Encoding setting.
>   - Character encoding list in View/Character Encoding is not updated
>     by change(add/remove) at View/Character Encoding/Customize
>     until restart of Seamonkey 2.
> I couldn't reproduce it after restart of Seamonkey 2.
You're right. When I use my old profile (the version of Sm created this profile is much older than 2.0b1pre), encoding list menu is not updated. It's updated when profile created by Sm 2.1a1pre is used.

    
    

    
  


  
But Version 2.0b1pre works. The first time that mail is selected, its format is correctly detected.

    
    

    
  
(In reply to comment #16)
> mail not redisplayed in UTF8 properly

It's same display of Chinese characters(with Euro sign, some U+Fxxx) of screen shot attached to comment #14.

I could observe problem consitently at last with View/Message Body As=Original HTML. (I probably mainly tested with Simple HTML or Plain Text.)

(a) Garbled display since initial when View/Message Body As=Original HTML.
    Can't display as expected by Vie/Character Encoding setting change.
      Sm(1.9.1) 2009/7/14 build : Produced
      Sm(1.9.1) 2009/7/21 build : Not produced
      Sm(1.9.2) 2009/7/20 build : Produced
(b) Header & garbled Chinese characters(with Euro sign, some U+Fxxx)
      Sm(1.9.1) 2009/7/14 build : Produced
      Sm(1.9.1) 2009/7/21 build : Produced
      Sm(1.9.2) 2009/7/20 build : Produced
(c) Page display of Content-Type: message/rfc822 with no charset
      Sm(1.9.1) 2009/7/21 build : Still displays Euro sign, some U+Fxxx.

Confirming.

Can you see problem (a) with View/Message Body As=Simple HTML / Plain Text?
Can you see problem (a) with newer build of SeaMonkey/2.1a1pre?

For bug summary.
> Charset specified in inline HTML header is ignored

What do you mean by "inline HTML header"? <meta> tag in HTML source?
Mail header of Content-Type: in mail source?
If former, answer to bug summary is INVALID. Please change bug summary appropriately, in order to avoid misunderstanding and misleading, and for ease of search.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: intl

    
    

    
  
(In reply to comment #15)
> Just pure curiosity, how did you import that .eml file as real mail? I can't find the magic door.

Importing of .eml via Drag&Drop is not available yet(work is in progress). We need to add "From ..." line at top of .eml file manually.
(0) Assume path of nod32.eml = C:\DIR\nod32.eml
(1) Copy a small mail folder file of Sm Mail to C:\DIR\from.txt
(2) Edit C:\DIR\from.txt by text editor, remove all lines except first "From ..."
(3) At command prompt
    C:
    CD C:\DIR
    COPY from.txt + nod32.eml mbox
(4) Copy mbox to Sm Mail's mail directory and restart Seamonkey.

    
    

    
  
(In reply to comment #17)
> (In reply to comment #16)
> > mail not redisplayed in UTF8 properly
> 
> It's same display of Chinese characters(with Euro sign, some U+Fxxx) of screen
> shot attached to comment #14.
> 
> I could observe problem consitently at last with View/Message Body As=Original
> HTML. (I probably mainly tested with Simple HTML or Plain Text.)
> 
> (a) Garbled display since initial when View/Message Body As=Original HTML.
>     Can't display as expected by Vie/Character Encoding setting change.
>       Sm(1.9.1) 2009/7/14 build : Produced
>       Sm(1.9.1) 2009/7/21 build : Not produced
>       Sm(1.9.2) 2009/7/20 build : Produced
> (b) Header & garbled Chinese characters(with Euro sign, some U+Fxxx)
>       Sm(1.9.1) 2009/7/14 build : Produced
>       Sm(1.9.1) 2009/7/21 build : Produced
>       Sm(1.9.2) 2009/7/20 build : Produced
> (c) Page display of Content-Type: message/rfc822 with no charset
>       Sm(1.9.1) 2009/7/21 build : Still displays Euro sign, some U+Fxxx.
> 
> Confirming.
> 
> Can you see problem (a) with View/Message Body As=Simple HTML / Plain Text?
> Can you see problem (a) with newer build of SeaMonkey/2.1a1pre?
> 
> For bug summary.
> > Charset specified in inline HTML header is ignored
> 
> What do you mean by "inline HTML header"? <meta> tag in HTML source?
> Mail header of Content-Type: in mail source?
> If former, answer to bug summary is INVALID. Please change bug summary
> appropriately, in order to avoid misunderstanding and misleading, and for ease
> of search.
Summary: Charset specified in inline HTML header is ignored → Charset specified in <meta> tag in HTML source is ignored

    
    

    
  
(In reply to comment #17)
> Can you see problem (a) with View/Message Body As=Simple HTML / Plain Text?
No.
> Can you see problem (a) with newer build of SeaMonkey/2.1a1pre?
Yes.
Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090720 SeaMonkey/2.1a1pre
> 
> For bug summary.
> > Charset specified in inline HTML header is ignored
> 
> What do you mean by "inline HTML header"? <meta> tag in HTML source?
> Mail header of Content-Type: in mail source?
> If former, answer to bug summary is INVALID. Please change bug summary
> appropriately, in order to avoid misunderstanding and misleading, and for ease
> of search.
Done.

    
    

    
  
> Charset specified in <meta> tag in HTML source is ignored

If this bug is for real mail case, your claim becomes "charset in <meta> should be used". I think charset in MIME header of Content-Type: should be used as done for HTTP & HTTP header of Content-Type:. So this bug is INVALID as I said before, if this bug is for real mail case and bug summary properly represents problem which you considers "caused by flaw in code of Sm".

If this bug is for message/rfc822 page(and .eml file. comment #0 looks to be for this case), I think phenomenon is;
 - Seamonkey uses charset in HTTP Content-type: header
 - Seamonkey doesn't use charset in MIME Content-type: header
   when no charset in HTTP Content-type: header 
 - Seamonkey 1 looks to use charset in <meta> tag upon rendering HTML mail
 - Seamonkey 2's behaviour is one of next:
   - don't use charset in <meta> tag
   - try to use charset in <meta> tag, but falls back to default character
     encoding for some reason.
In this case, current bug summary doesn't represent problem propely.

Although comment #0 refers to .eml file, your initial problem was "incorrect display of real mail" as you said in comment #11. So I think you are better split this bug to three bugs: (a) real mail case (SeaMonkey Mail's problem), (b) garbled display when click of View/Character Encoding/Auto Detect/Off (SeaMonkey Mail's problem), and (c) message/rfc822 page(and .eml) case which is SeaMonkey Browser's problem.

    
    

    
  
(In reply to comment #21)
> > Charset specified in <meta> tag in HTML source is ignored
> 
> If this bug is for real mail case, your claim becomes "charset in <meta> should
> be used". I think charset in MIME header of Content-Type: should be used as
> done for HTTP & HTTP header of Content-Type:. So this bug is INVALID as I said
> before, if this bug is for real mail case and bug summary properly represents
> problem which you considers "caused by flaw in code of Sm".

Just tell me what the summary should be and I'll update it.

> 
> If this bug is for message/rfc822 page(and .eml file. comment #0 looks to be
> for this case), I think phenomenon is;
>  - Seamonkey uses charset in HTTP Content-type: header
>  - Seamonkey doesn't use charset in MIME Content-type: header
>    when no charset in HTTP Content-type: header 
>  - Seamonkey 1 looks to use charset in <meta> tag upon rendering HTML mail
>  - Seamonkey 2's behaviour is one of next:
>    - don't use charset in <meta> tag
>    - try to use charset in <meta> tag, but falls back to default character
>      encoding for some reason.
> In this case, current bug summary doesn't represent problem propely.
> 
> Although comment #0 refers to .eml file, your initial problem was "incorrect
> display of real mail" as you said in comment #11. So I think you are better
> split this bug to three bugs: (a) real mail case (SeaMonkey Mail's problem),
> (b) garbled display when click of View/Character Encoding/Auto Detect/Off
> (SeaMonkey Mail's problem), and (c) message/rfc822 page(and .eml) case which is
> SeaMonkey Browser's problem.

I only care about (a). Besides that, I didn't want 2 of them to be marked as duplicated.

    
  
Summary: Charset specified in <meta> tag in HTML source is ignored → charset in <meta> should be used

    
    

    
  
New bug summary.
> charset in <meta> should be used

Your case is for next mail, isn't it?
>   Content-Type: text/html; charset="utf-8"
>  (snip)
>   <meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
>   HTML source is written in UTF-8
Are you really requesting decode of the HTML data with GB2312?

    
    

    
  


  
nod32.eml data is sent with Content-Type: text/html; charset=GB2312 by B.M.O. This page produces display of header lines + Chines crar + Euro sign + some U+Fxxx. It's same as display upon click of View/Character Encoding/Auto Detect/(Off) while mail is  displayed in UTF-8 properly.

    
    

    
  
(In reply to comment #23)
> New bug summary.
> > charset in <meta> should be used
> 
> Your case is for next mail, isn't it?

I changed it just because you mentioned:
>If this bug is for real mail case, your claim becomes "charset in <meta> should
> be used".
and it is a real mail case.

> >   Content-Type: text/html; charset="utf-8"
> >  (snip)
> >   <meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
> >   HTML source is written in UTF-8
> Are you really requesting decode of the HTML data with GB2312?
No. Just want to it to be displayed correctly.

BTW, I didn't realize there is so much difference between Mail and Browser. I use to believe they are similar.

    
    

    
  
(In reply to comment #25)
> > Are you really requesting decode of the HTML data with GB2312?
> No. Just want to it to be displayed correctly.

If so, summary should be "charset in <meta> should NOT be used". Is it wrong?
Changing bug summary, to avoid misleading and for ease of search.
Summary: charset in <meta> should be used → If <meta ... content="text/html; charset=GB2312"> exists in HTML mail source,  HTML mail of Content-Type:text/html;charset=UTF-8(HTML data is encoded in UTF-8, probably converted) is displayed using GB2312

    
    

    
  
Some questions again.

(for mail display case, (a) in comment #17)
Can you see garbled display with View/Message Body As=Simple HTML and Plain Text?
Can you see garbled display with View/Message Body As=Original HTML with newer build?

Mail you attached to this bug has two problems.
 1. RFC2047 encoded Subject: is split at wrong position.
 2. Even though Content-Type:...UTF-8 and HTML source is encoded in UTF-8,
    HTML source has meta tag with charset=gb2312. 
    <meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
This is probably result of character encoding conversion from GB2312 to UTF-8 at mail server. (i.e. both 1. and 2. are bug of converter on mail server.)
What kind of mail server do you use? Which provider? POP3? IMAP? Web Mail?

    
    

    
  
(In reply to comment #26)
> (In reply to comment #25)
> > > Are you really requesting decode of the HTML data with GB2312?
> > No. Just want to it to be displayed correctly.
> 
> If so, summary should be "charset in <meta> should NOT be used". Is it wrong?
> Changing bug summary, to avoid misleading and for ease of search.

Both UTF8 and GB2312 should be used. UTF8 used to decode the HTML. GB2312 used to display the HTML after it's decoded.

    
    

    
  
(In reply to comment #27)
> Some questions again.
> 
> (for mail display case, (a) in comment #17)
> Can you see garbled display with View/Message Body As=Simple HTML and Plain
> Text?
> Can you see garbled display with View/Message Body As=Original HTML with newer
> build?
> 
You can find my answers in comment #20. Nobody has tried to fix this problem. I don't see a reason to test it with newer build.

> Mail you attached to this bug has two problems.
>  1. RFC2047 encoded Subject: is split at wrong position.
As you've already seen, I filed a bug for it at
https://bugzilla.mozilla.org/show_bug.cgi?id=505068.

>  2. Even though Content-Type:...UTF-8 and HTML source is encoded in UTF-8,
>     HTML source has meta tag with charset=gb2312. 
>     <meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
> This is probably result of character encoding conversion from GB2312 to UTF-8
> at mail server. (i.e. both 1. and 2. are bug of converter on mail server.)
> What kind of mail server do you use? Which provider? POP3? IMAP? Web Mail?
It's not my mail server but one used by ESET China that created the email. Checking the email header might reveal some information.

Yet I don't think it's necessary to find out anything about the server as the format of the email is correct. Though, I'm not sure about whether the position in item 1 is specified anywhere.

I can attach the decoded HTML data so that you can compare it with the result of Sm Mail. Please mention it if it is helpful.

    
    

    
  
(In reply to comment #29)
> You can find my answers in comment #20.

Oh, sorry, I missed it.

> Nobody has tried to fix this problem. I don't see a reason to test it with newer build.

See Comment #17 (a) again.
Problem (a) occurred with 1.9.1-7/14 build, and you say no problem with 1.9.1-7/17 build, and no problem with 1.9.1-7/20 build too. It indicates that something was changed between 7/14 and 7/17 and problem of (a) on 1.9.1 build disappeared.

For 1.9.2 build, you say problem occurred with 1.9.2-7/18 build, and I could still see problem with 1.9.2-7/20 build. Because landing of changes on 1.9.2 is usually postponed(1.9.1 is real main trunk for Tb 3), check with newer builds is required to know whether problem of (a) on 1.9.2 is 1.9.2 particular problem or not.
I don't think 1.9.2 particular problem, because problem of (b) is common.

> Yet I don't think it's necessary to find out anything about the server (snip)

It's not for this bug. It's for users of "ESET China" and mail recipient from user of "ESET China" like you. Because at least two problem exist at server side, we users are better to report the problem to ISP for other users. 

> as the format of the email is correct.

Why can the mail be correct mail? Item-1 is apparent RFC violation which is probably produced by bug of software used by mail server.

    
    

    
  
(In reply to comment #30)
> See Comment #17 (a) again.
> Problem (a) occurred with 1.9.1-7/14 build, and you say no problem with
> 1.9.1-7/17 build

There must be some misunderstanding. I found the problem with 1.9.2-7/18. I haven't downloaded 1.9.1-7/17. The flawless version I used is 1.9.1-7/2.

> check with newer builds is required to know whether problem of (a) on
> 1.9.2 is 1.9.2 particular problem or not.

The latest Win32 version is still 1.9.2-7/20.

> > as the format of the email is correct.
> 
> Why can the mail be correct mail? Item-1 is apparent RFC violation which is
> probably produced by bug of software used by mail server.

Item 1 is the one that I am not sure of. Regardless that, I get a valid HTML file after decoding.

I Just found another email in my inbox displayed as junk. It's encoded in BASE64. The email header together with encoded mail content is displayed. Sorry, I can't attach that email because of sensitive data. It shouldn't be difficult to find a BASE64 encoded email.

    
    

    
  
(In reply to comment #31)
> haven't downloaded 1.9.1-7/17. The flawless version I used is 1.9.1-7/2.

Sorry for my misunderstanding.
  1.9.1-7/02 : You checked. flawless. 
  1.9.1-7/14 : I checked.   problem of (a) occurred.
  1.9.1-7/17 : I checked.   problem of (a) didn't occur.
It looks regression after 7/02 and resolved between 7/14 and 7/17.

> The latest Win32 version is still 1.9.2-7/20.

I thought Win32 7/24 build is available when I saw seamonkey-2.1...mar 24-Jul-2009 at top of list... When newer win32 build will be available, check please. 

FYI.
Problem of (b) in Comment #17 (header display when click of View/Character Encoding/Auto Detect choice) was indepent phenomenon/problem from this bug and was irrelevant to mail data of this bug.
  - Header display when click of View/Character Encoding/Auto Detect choice
    always occurs on any mail.
  - Phenomenon is; Whole mail data is rendered as HTML source
    when View/Character Encoding/Auto Detect choice is clicked.
  - If mismatch between real encoding of HTML data and charset in <meta> tag
    exists, garbage is also displayed. (phenomenon with mail data of this bug)
I'll open separate bug for it.

    
    

    
  
FYI.
I've opened Bug 506504 for problem of (b) in Comment #17.

    
    

    
  
(In reply to comment #30)
> check with newer builds
> is required to know whether problem of (a) on 1.9.2 is 1.9.2 particular problem
> or not.
Just installed 1.9.2-8/3, but still no luck.

    
    

    
  
FYI.
MIME Type=message/rfc822 case and .eml file case is probably long living Bug 206421 or Bug 227360 of Mozilla (displayed by Browser).
And, if mail structure is changed to multipart/mixed, and if different character encoding/charset is used for text/plain part and text/html part, Bug 367240 is easily be observed with any Seamonky(Sm 1.x, Sm 2 191, Sm 2 192) for all of mail in mail folder, .eml file, message/rfc822 page.

(In reply to comment #34)
> Just installed 1.9.2-8/3, but still no luck.

Me too.

Comment #0 easily mis-leads to ".eml file" case. And your test mail forces user to analyze garbage in subject header. And, as many problems were found in this bug with your test mail, this bug is already messy sufficiently.
We are probably better to open separate bug for original issue, issue of "garbled display of mail in mail folder" of Seamonky 1.9.2 build only, with simpler, shorter, non-mis-leading test mail with clear description than comment #0. I'll do it.

    
    

    
  
Zane U. Ji, I've opened Bug 508946 for original issue, issue of "garbled display of mail in mail folder", Seamonky 1.9.2 only issue and View/Message Body As/Original HTML only issue.

    
    

    
  
I want to spend some time on this bug. The document says I should assign the bug to myself. However, I don't have the privilege to do that. So I just leave a note here. If I haven't uploaded anything in a week, it's safe to assume that I failed and anybody else can take over the job.

    
    

    
  


  
In addition to the patch, I found out why mail header is displayed when I changed how character is auto-detected, which is mentioned in Comment #12. It seems I should file a new bug if there is not one for that problem. Before submitting a patch, I'd like to dig deeper and see what's hiding there to avoid screwing things up.

        Attachment #405746 -
        Flags: superreview?(bienvenu)

        Attachment #405746 -
        Flags: review?(dmose)

    
    

    
  


  

        Attachment #405746 -
        Attachment is obsolete: true

        Attachment #405749 -
        Flags: superreview?(bienvenu)

        Attachment #405749 -
        Flags: review?(dmose)

        Attachment #405746 -
        Flags: superreview?(bienvenu)

        Attachment #405746 -
        Flags: review?(dmose)

    
    

    
  
Comment on attachment 405749 [details] [diff] [review]
Fixed a regression & character set menu not working problem in mailnews

This is a small enough patch that r+sr should be just fine.  Since I'm about to get on a plane and bienvenu has graciously agreed to do it, I'm handing off to him...

        Attachment #405749 -
        Flags: review?(dmose) → review?(bienvenu)

    
    

    
  
Root problem is Bug 513249(See 508946 Comment #1, please). I think patch is better to be proposed in non-confusing Bug 513249.

    
    

    
  
WADA, if I generate a try server build with this patch, can you try it out and report if it fixes these various bugs in Thunderbird? Thx in advance!

    
    

    
  
(In reply to comment #43)

Yes I can, if MS Win build. I'll report in Bug 513249 and Bug 508946.

    
    

    
  
I think tryserver is a bit broken - probably the move to the trunk...gozer, can you look at those, in particular, the win32 build?

    
  

        Attachment #405749 -
        Flags: superreview?(bienvenu)

        Attachment #405749 -
        Flags: superreview+

        Attachment #405749 -
        Flags: review?(bienvenu)

        Attachment #405749 -
        Flags: review+

    
    

    
  
Comment on attachment 405749 [details] [diff] [review]
Fixed a regression & character set menu not working problem in mailnews

You don't have to check the rv && the i18url - one is sufficient. I'll fix it before landing.

+  if (NS_SUCCEEDED(rv) && i18nurl)

    
    

    
  
fix checked in, thx, Zane.
Status: NEW → RESOLVED
Closed: 15 years ago → 15 years ago
Component: MailNews: Message Display → Backend
Product: SeaMonkey → MailNews Core
QA Contact: message-display → backend
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.1a1

    
    

    
  
Checked with next builds.
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091118 Shredder/3.1a1pre
> Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.3a1pre) Gecko/20091118 SeaMonkey/2.1a1pre
After the patch, Bug 513249(non utf-8, charset in meta) and Bug 508946(utf-8, wrong charset in meta, original problem of this bug) couldn't be reprocuced with these builds. Problem of Bug 528736 also couldn't be reprocuced.
Fixed/Verified.
Status: RESOLVED → VERIFIED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: