Closed Bug 8903 Opened 25 years ago Closed 25 years ago

Japanese page display of attachment URL is broken

Categories

(MailNews Core :: MIME, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 8899

People

(Reporter: momoi, Assigned: nhottanscp)

References

()

Details

** 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.
<The part about displaying in the message pane after clicking on an URL is part
of another reported bug already.>
Status: NEW → ASSIGNED
Target Milestone: M8
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))'.......
Assignee: rhp → nhotta
Status: ASSIGNED → NEW
Naoki,
Isn't this the same as another bug you are working on for this issue.

- rhp
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
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 ***
QA Contact: lchiang → momoi
change qa contact to Kat.
Status: RESOLVED → VERIFIED
Verified Dup...see Bug 8899
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.