8903 - Japanese page display of attachment URL is broken

Status: VERIFIED DUPLICATE of bug 8899

(MailNews Core :: MIME, defect, P3)

Description

[Katsuhiko Momoi]

** Observed with 6/25/99 Win32 M8 build **

We have a message in our International Smoketest file (see URL above).
Of the 5 messages we use, the 3rd one from top (or the bottom)
contains an attachment which is not showing inline but only
as an URL.
When you click on this URL, 5.0 tries to display it in the
message viewing window rather than in a browser window, which
was the standard behavior in 4.x.

The Japanese display of such a case is broken. It does not seem like
proper conversion is taking place for display.

This particular message has an atatchment encoded in Shift-JIS/CTE=B64.
We should also be able to take care of EUC-JP/CTE=B64 and ISO-2022-JP/CTE=
B64.

Comment 1

[lchiang]

<The part about displaying in the message pane after clicking on an URL is part
of another reported bug already.>

Comment 2

[rhp (gone)]

Actually, I have a guess at what's going on here. Naoki, tell me if this makes
sense. This isn't an issue with the "mail.inline_attachments" pref or the
content-disposition header. They are working as they should, but gecko is not
displaying the output from libmime for the following reason.

First, to see that we are outputting the page inline, do the following:

1 - bring up messenger 5.0 and display the problem message
2 - now bring up a 5.0 browser window and load the URL:
file:///c:/temp/tempMessage.eml?header=none
(note: you probably won't see anything past the URL)
3 - Do a "View Source" - notice how there is source output for the entire web
page.

Now, this is what I think is happening. We start decoding everything to UTF-8
and the message and the body part is encoded with charset = "iso-2022-jp". When
we hit the web page, we start decoding that message to UTF-8, but there is no
charset= on the part, so we fall back to the body, which is iso-2022-jp. Now,
we do this conversion and output to Gecko, but the web page has a <META
HTTP-EQUIV ="Content-Type" ="text/html; charset=x-sjis> line. I assume that
Gecko is listening to this and trying to display UTF-8 data (which is probably
wrong to begin with) as x-sjis.

So, the bug about the content-disposition is invalid, but this is a problem we
need to figure out. Naoki, do you have any ideas?

Here is the output from libmime for the message body:

< META HTTP-EQUIV ="Content-Type" ="text/html; charset=UTF-8">< !doctype html
public "-//w3c//dtd html 4.0 transitional//en">< html>
ã..ã..ã.¯SJISã.®ã..ã.¼ã.¸ã.§ã..ã..< br>& nbsp;< p>< A HREF
="http://home.netscape.com/ja/"> http://home.netscape.com/ja/< /A>< /html><
BASE HREF ="http://home.netscape.com/ja/">< HTML>< HEAD>< TITLE> Netcenter
.Ö.æ.¤.±.»< /TITLE>< META HTTP-EQUIV ="Content-Type" ="text/html;
charset=x-sjis">< META http-equiv =PICS-Label ='(PICS-1.1
"http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0)'>  < META
http-equiv =PICS-Label ='(PICS-1.1 "http://www.classify.org/safesurf/" l gen
true r (SS~~000 1))'

< META HTTP-EQUIV ="Content-Type" ="text/html; charset=UTF-8">< !doctype html
public "-//w3c//dtd html 4.0 transitional//en">< html>
ã..ã..ã.¯SJISã.®ã..ã.¼ã.¸ã.§ã..ã..< br>& nbsp;< p>< A HREF
="http://home.netscape.com/ja/"> http://home.netscape.com/ja/< /A>< /html><
BASE HREF ="http://home.netscape.com/ja/">< HTML>< HEAD>< TITLE> Netcenter
.Ö.æ.¤.±.»< /TITLE>< META HTTP-EQUIV ="Content-Type" ="text/html;
charset=x-sjis">< META http-equiv =PICS-Label ='(PICS-1.1
"http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0)'>  < META
http-equiv =PICS-Label ='(PICS-1.1 "http://www.classify.org/safesurf/" l gen
true r (SS~~000 1))'.......

Comment 3

[rhp (gone)]

Naoki,
Isn't this the same as another bug you are working on for this issue.

- rhp

Comment 4

[nhottanscp]

The remaining issue about this is charset auto detection accuracy (8899).
There is also a charset related problem for clicking a link inside the message
pane. But that is a separate problem from this bug (not attachment problem).

*** This bug has been marked as a duplicate of 8899 ***

Comment 5

[lchiang]

change qa contact to Kat.

Comment 6

[Jay Patel [:jay]]

Verified Dup...see Bug 8899